An Approach to Product Roadmapping in Small Software Product Businesses

Transcription

1 Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) G-Tool 3.0,.0,.0, Web Dev kit U I WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit G-Tool engine Generation 1, Writ. Writ.,, /2002 3,Writ., Writ 2, Writ.,, Sales, Sales, Sales, 1 Writ, An Approach to Product Roadmapping in Small Software Product Businesses Jarno Vähäniitty, Casper Lassenius & Kristian Rautiainen The Purpose of This Paper Present an approach to planning and communicating Release contents, timing and roles Keeping in mind the software components life cycles and the whole product for small software product businesses Present our experiences from applying the model in three such companies 2 1

2 Agenda Introduction Product roadmapping in SW product business A model for product roadmapping Experiences from applying the model Conclusion and directions for further work Questions and Comments 3 Success Factors in SW Product Business from an Engineering Perspective Capability to invent new solutions and realise them as software Releasing the solution as products and product upgrades with The right amount of features and quality Within an open market window For the latter, a systematic approach for managing the contents, timing and roles of future product releases as well as product architecture is needed 2

3 Specifically... Contents Linking product features to business requirements and market opportunities Deciding which features to include in which release Timing Roles Identifying and exploiting a window of opportunity Making necessary trade-offs between functionality, quality and time-to-market based on assessing the product against its competitors. The type of the release (major, minor, patch etc.) Intended business implications for the company The planned audience for the release Components lives and the whole product perspective Success often involves evolving both the individual products and the technologies they are based on at the same time What is it that you sell (besides the chunks of code)? SME s Risk Extensive Rework and Market Failure due to Shortcomings in Product and Release planning A systematic approach is often missing because of Inexperience Time-to-market pressures [Bosch, 2000] Lack of proper process infrastructure For example, requirements management [Kamsties et. al, 199] Key personnel often have truly cross-functional roles Architecting, installing the system, systems integration, consulting, sales Unclear priorities caused by lack of long-range planning Overbooking of resources is common Some important activities do not receive enough attention Survival pressures make hacking the product to satisfy the needs of initial customers a tempting idea, usually to the detriment of the product architecture [Clements & Northrop, 2001] 6 3

4 Little Guidance Available for the Small for Connecting Feature and Product Planning to Business Planning Literature on NPD management literature addresses large companies with multiple product lines and / or business units Discussion of release management most often limited to The development process (e.g. [Bays 1999]) Architecture and reuse (e.g. [Bosch, 2000], [van Ommering, 2001]) Requirements (e.g. [Carlshamre et. al, 2001]) Also, SME s face the challenge of coherently expressing and communicating their plans Internally To various stakeholders such as venture capitalists and potential customers In our experience, release cycle planning seems to be the key ingredient in combining business planning to product development 7 What is Roadmapping? A popular metaphor for planning and portraying Use of scientific and technological resources and elements, and their structural relationships over a period of time. The process of roadmapping identifies, evaluates and selects strategic alternatives that can be used to achieve desired objectives [Kostoff & Schaller, 2001] The resulting roadmaps summarise and communicate the results of key business decisions [DeGregorio, 2000] Specifically, product roadmapping? Disciplined, focused, multiyear approach to product planning, with the roadmap s implementability viewed as important as its strategic value [Kostoff & Schaller, 2001].

5 Our Approach to Product Roadmapping Consists of a model for visualising product roadmaps, and a process outline for creating and updating such roadmaps based on the strategic mission and vision of the company The roadmap visualisation communicates the plans intuitively, as well as enforces a degree of accuracy through the use of formal notation The aim of the process is to define and concretise the company s plans for technology and product development Using the process should result in An understanding of the current and future situation from the perspective of the product mix An overview of the objectives and needs for new product releases Directions for extending and further developing the technological basis. 9 The Roadmap Visualisation Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) Activities G-Tool / ,.0,.0,, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit Composition, integration, (in some cases) reuse, Writ. Writ., G-Tool engine Generation ,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, Cumulative planned resource usage from the activities 10

6 The Roadmap Visualisation Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) /2002 G-Tool 3.0, requiring attention from product development.0,.0,, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit, Writ. Writ., G-Tool engine Generation ,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, 11 The Roadmap Visualisation Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) G-Tool / ,.0,.0, Release schedules for the product(s), Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit, Writ. Writ., G-Tool engine Generation ,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, 12 6

7 The Roadmap Visualisation Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) G-Tool 3.0, /2002.0,.0,, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit, Writ. Composition and development schedules of individual releases Writ., G-Tool engine Generation ,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, 13 The Roadmap Visualisation Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) G-Tool 3.0, /2002.0,.0,, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit, Writ. Writ., G-Tool engine Generation 1 Changes to the underlying technology 7 6 3,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, 1 7

8 Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q (Sales takes over here) Basictraining, Sales /2002 G-Tool 3.0,.0,.0, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit, Writ. Writ., G-Tool engine Generation , Writ., Writ 2, Writ.,, Sales, Cor Sales, Cor Sales, 1 Writ, Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q (Sales takes over here) Basictraining, Sales /2002 G-Tool 3.0,.0,.0, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit G-Tool engine Generation 1, Writ. Writ.,,, 7 6 3, Writ., Writ 2, Writ.,, Sales, Cor Sales, Cor Sales, 1 Writ, Visualisation Elements Explained (1/2) Product release Consists of integrating the related product components and platform(s), doing system testing and error correction, as well as performing other product release activities Three kinds of possible releases in the notation Major, minor and patches Product component Business requirements translated as software Relatively independent (groups of) features depicted as product components when necessary Usually defined software as well [Sommerville, 2001] Product platform software asset(s) on top of which the product is built and expanded on May be generic enough to be used in other products as well 1 Visualisation Elements Explained (2/2) Classified and dealt with based on the kind of attention they need from product development Product accessories A one-time effort requiring product development resources to fulfil a need common to many customers Typically developed for a specific customer, but are to be included as part of the standard offering Depicted as product components Customer-specific development services Depicted on the service layer Outcome is limited to the customer receiving the service (installation, systems integration) Other services Do not appear to require attention from product development Not necessary to include these kinds of services into the produc t roadmap 16

9 A Four-Step Process for Product Roadmapping 1) Define strategic mission and vision Clarify and communicate what business the company is in 2) Scan the environment Choose position and focus, assess the realism of the product vision and examine what technologies should be used 3) Revise and distil the product vision as product roadmaps Establish release cycle, objectives for releases and allocate resources. Record decision rationale with business requirements ) Estimate product life cycle and evaluate the mix of development efforts planned Check sanity. Assess whether the planned development is parallel to the product vision The steps in the process should be performed periodically (quarterly to twice a year) to adjust the roadmap to new information and changing market situations Smaller updates necessary to ensure the roadmaps always hold current information (once per 2 weeks to bimonthly) 17 Approach developed and applied in co-operation with three small software companies ToolCo (1 employees) Applications and software development tools for Internet-, intranet- and extranet environments Most of the application experiences come from this case TeamCo (~0) Solutions that facilitating group interaction for mobile operators, service providers and enterprises MobAppsCo (~0) Mobile business solutions and professional services for mobile o perators and enterprises. 1 9

10 Conducting Roadmapping at ToolCo The company had ideas on how to productize their toolkit for rapid creation of browser-enabled user interfaces Roadmapping was conducted in -7/2001 Mainly carried out by the CEO, and required about one man-month of effort Involved Planning the release cycle Schedules for the major releases and their contents, Considering what whole-product issues needed to be taken into account along the way Outcome A clearer understanding of what had to be achieved in order to launch the product, Realising the schedule and timing implications of sales, marketing and other aspects not directly related to development The CEO was positive he would use a similar approach in the future for product and release planning 19 Lessons from ToolCo Estimating the life cycles and financial implications of products, components and platforms was seen both important and challenging Identifying and analysing the competition was found difficult Moral of the exercise = forces to think ahead and state current expectations, as opposed to obtaining accurate forecasts of future cash flow or competitors strengths, weaknesses and plans The visualisation was found extremely helpful Development plans of the product, its parts and planned resource allocation over time in one picture These issues had previously been found difficult to express and communicate Feedback resulted in several adjustments Introduction of the service layer Explicit resource types Simplifying the notation for minor releases and release composition

11 Conclusion Product roadmapping can be used to bridge the gap between management, marketing and product development Forces management to consider both product positioning and development aspects at the same time Important to account for services in the product roadmap Helps make resource allocation trade-offs between product and service development A common conceptual view of the product may be lacking even when the development organisation is small Because a sense of urgency is always present when dealing with small companies, light-weight but systematic process for long-range planning seems necessary 21 Conclusion By taking a long-term view into release management, product roadmapping can help bring together the perspectives of business management and software development Concretises and communicates the plans so that they can be acted on or refuted when necessary Tracking service development and actual servicing jointly with product and release planning helps exploit potential synergies between the product and the services offered 22 11

12 Further Work More empirical experience from using our approach! Specifically, we want to assess the cost and potential payoff of doing product roadmapping, in terms of Effort spent The kinds of insights and results gained from the exercise Toward this end, we are Outlining a repeatable launch and an incremental rollout plan for establishing product roadmapping in SME s Identifying the essential product development decisions the roadmapping process should address from the perspective of small companies 23 Questions and Comments! Full text for the paper available at 12

13 Roadmap Visualisation Layers Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) /2002 G-Tool 3.0,.0,.0,, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit, Writ. requiring attention from product development Release schedules for the product(s) Composition and development schedules of individual releases Writ., G-Tool engine Generation 1 Changes to the underlying technology 7 6 3,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, 2 Roadmap Visualisation Elements Q1 Q2 Q3 Q Q1 Q2 Q3 Q Q1 Q2 Q3 Q Basic training, Sales (Sales takes over here) Activities G-Tool / ,.0,.0,, Web Dev kit WAP Dev kit Mobile (G3) Dev kit PDA Dev kit DigiTV Dev kit Composition, integration, (in some cases) reuse, Writ. Writ., G-Tool engine Generation ,, Writ. Writ 2,,, Writ. Sales, Sales, Sales, 1 Writ, Cumulative planned resource usage from the activities 26 13