Product Strategy Decisions in Small Software Product Businesses – A Framework and Experiences

1. Product Strategy Decisions in Small Software Product Businesses –A Framework and Experiences • Submitted on 8.1.2003 • Jarno Vähäniitty’s master’s thesis • Helsinki University of Technology • Edited by Rauli Käppi, Software Business Program

2. Introduction • Product strategy has been identified as the most important management area of software product business • Product strategy answers to the questions: (McGrath 2000) • Where are we going? • How will we get there? • Why will we be successful • The function of a product strategy is to link the company’s product development to its business strategy (McGrath, Anthony & Shapiro 1996)

3. Introduction cont. • The process for making product strategy decisions in a company is referred to as the product strategy process • The formulation of product strategy can be more systematic in larger companies – in smaller software companies the activities are carried out in more ad hoc –manner. • In smaller companies the formulation is more often based on key personnel’s opinions than systematic decision making process and fully informed decision makers

4. Introduction cont. • In small software product companies (below 50 employees) the roles of persons can be cross-functional, relating to architecture design, deploying the system, customer-specific tailoring, consulting and sales • The research carried out with larger software and / or product oriented companies is not always applicable to smaller companies

5. Research problem • How can product strategy decision-making in small software product businesses be supported? • What issues should product strategy decision-making entail? • How well are these issues currently handled in small software product businesses and is the state-of-practice satisfactory? • What has been proposed in literature to support product strategy decision –making, and how does this support fit the small business context? • Provided there is a gap between the needs and the support found, how can this gap be overcome? • Does the proposition for overcoming the gap between the needs and support found facilitate product strategy decision-making in practice?

6. Methodology • Answers are sought through literature study, the construction of a framework, and applying the framework to case companies • The construction process of the framework consists of two approaches conducted in parallel, a theoretical and empirical one, and of combining their results

7. Scope • The study is does not involve: • Software development departments in large companies • Hardware development • Explicit analysis of the impact of business environment and business model on product strategy decision-making

8. Decision perspective to formulating and enacting product strategy • The main decisions made while setting up a product development project are: • Product strategy and planning • Product development organization • Project management • Decisions made within a project • Concept development • Supply chain design • Product design • Performance testing and validation • Production ramp-up and testing

9. Decision making in small companies • The division between in- and outside the project decisions can sometimes be unclear • The decision-making roles are not always similarly separate as can be assumed from the previous slide

10. Common problems in New Product Development (NPD) • Cycle-time and pacing guidelines are not used to validate development schedules • Poor execution of development due to lack of common understanding of the development process, for example cycle-time guidelines • Unclear product strategy process results in product strategy being formulated superficially as part of annual budgeting • No explicit consideration for company growth, product mix or short and long-range emphasis in product development decision-making

11. Common problems in NPD cont. • Product strategy is formulated without involving the customer interface • Competitive positioning is unclear and the role of competitor analysis shallow • Strategic decisions on where the product is going are made in frustration by developers because senior management has not made them • Decisions are made too late, for example when considerable costs have already been committed • Fire-fighting decisions are made without the context of development priorities

12. Common problems in New Product Development (NPD) cont. • Failure to invest in current and future core technologies • Decisions are based on inadequate information because the proper level of detail is unknown • Unnecessarily long development cycles because technology development is not decoupled from product development • Decision points or milestones are not defined

13. 3 small studied software companies • In the beginning of the study the companies indicated having many (if not all) of the aforementioned problems • Firefighting was reported as the most common mode of operations • An implicit assumption (or hypothesis) of the study is to be able to improve the situation of the 3 companies through knowledge and guidelines

14. Strategic planning • Textbook approach to strategic planning is (Minzberg, Ahlstrand & Lampel 1998): • Analyze the industry • Select strategy • Build tactics around the selected strategy • Critics: • All is based on theoretical ideals • Not in direct connection with the real world • Outcome from the planning is almost always “off” from the later discovered – original planning did not include all the factors

15. Strategic planning cont. • Regardless of the criticism, companies need to plan things – the alternative is chaos • Important point to be learned here: The dilemma is to commit to a future (with plans) while retaining the flexibility to notice and adjust to the real future as it arrives • Small companies should rely more on information provided by analysis and less on intuition – the use of analytical approaches should be increased

16. Strategic planning cont. • Strategic plans should be treated as a rough roadmap and budgetary guideline, and not as a straitjacket that limits from adapting to the future as in unfolds (Brown & Eisenhardt 2002) • General conclusion in literature dealing with innovation management is that strategic planning, as well as the product development process itself should be no more formal than absolutely necessary (Eisenhardt & Sull 2001), (Thomke & Reinertsen 2001)

17. NPD – portfolio management • New product development, managing development projects / products as portfolios can be seen as a generic link between the company’s strategy and its product strategy • The objectives of portfolio management: • To maximize the value of the development project portfolio • To link it to the company’s strategy • To balance it on relevant dimensions (short vs. long term, current vs. new platforms, high vs. low risk, research vs. development, etc.)

18. NPD – portfolio management cont. • Criticism: • Multi-project, portfolio-based project screening approaches have their roots in large companies with multiple product / project alternatives and large managerial staff • The direct applicability to small software product companies can be questioned (due to lack of multiple product alternatives and similar decision-making staff and process) • Very little specific advice is offered how to actually develop a software project incrementally in a small software product company

19. NPD and strategic planning • Basic portfolio management principles are likely to be useful for increasing small companies’ awareness of essential product strategy decision-making issues • Many traditional techniques, such as roadmapping can be adapted to small software businesses with reasonable adaptation work

20. The benefit in strategic planning in small software product companies • Increasing awareness of the strategic decision-making and relevant process is the first step to actually improving them • Awareness promotes Coherence • Coherence means recognizing and dealing with the present using actions that make inherently sense to the participants, rather than focusing too much on the future and what company wants to be (Lissack & Roos 2001)

21. Different types of companies

22. Characteristics of product business • Amount of customer-specific effort is typically small • Financial and technical risks are carried out by the company • Potential for higher marginal returns on scale • Competitiveness and new product versions • Role of product complementarity (supporting existing products with a new one) • Relative relevance of management areas

23. Characteristics of product business cont. • Feature elicitation and valuation are based on dynamic criteria and in-house domain expert’s judgment • Complexity of market segmentation (usage, rates, customer and / or user capabilities, technology, preferences and demographics) and product differentiation (price, features, performance, conformance, reliability, style, services, and image) • Pressures from time-to-market and increasingly shortened release cycles

24. Characteristics of product business cont. • Iterative and incremental product development process recommended • Simultaneous development of both technologies and products may be necessary • Higher initial investments in the design of the product architecture • Motivation for process improvement • Role of quality assurance

25. Characteristics of small companies and managerial implications • Potential strengths from low cost-of-communication • Emphasized role of senior management • More roles than people • Individuals’ skills and competences • Pressures to secure financing • Local area of operations (indirect sales channels for full market reach) • Small companies (appear to) have less need for formal management procedures

26. Characteristics of small companies and managerial implications cont. • Role of quality assurance (not enough people to have a separate testing organisation) • Process improvement – potential strengths for small company – also potential pitfalls • Start-up characteristics

27. Constructing the theoretical framework- key product strategy decisions of small software product companies • Organisational (by whom, and where?) • Organisational model • Roles and responsibilities • Team staffing • Team physical arrangement and location • Investments in team collaboration • Portfolio management (what and when?) • Sales and marketing, Distribution channels • Servicing and deployment • Release management (incl. Operational perspective: release process and configuration management + strategic perspective: release contents, roles, types and timing)

28. Constructing the theoretical framework- key product strategy decisions of small software product companies cont. • Requirements (what and when, specifically?) • Elicitation • Specification • Allocation • Change management • Development strategy (how?) • Development models (Incl. type of development process, pacing, progress tracking and control and communication mechanisms among team members

29. Constructing the theoretical framework- key product strategy decisions of small software product companies cont. • Technology (by leveraging which technologies?) • Product architecture and employed technologies • Development infrastructure • Quality strategy (delivered with what emphasis?) • Decisions on what kind of testing is conducted and why • Project performance measurement

30. More about the research • Interviews in 3 companies how the product strategy work is carried out • These results are then described using the framework as a tool • The framework is analysed reflecting it with the companies’ practices • Finally the framework is refined and generalised

31. Case: SlipstreamResults of the interviews • Founded in 1996 and re-focused to its current operations in 1999 • Develops software products to stream and package audio and video over the internet. • Usage models / categories for their products have been identified such as: corporate communications (internet and intranet), web portals, banner ads, and video e-mail campaigns • Total of 30 employees, 19 in product development, 5 in sales, 3 in management and 3 in customer support

32. Case: Slipstream cont.Roles and responsibilities • Product managers are responsible for the feature set to be implemented in the project and end-user documentation • Project manager is responsible for progress tracking, how the product is designed and the features implemented, internal product-related documentation and post-release work such as bug-fixing • Test manager is responsible for the end product meeting the specifications, test documentation and other test-related efforts • The project manager leads a team of developers who do the actual implementation. The developers consult the product manager directly on feature details if needed • Senior product manager is responsible of reporting the progress of all ongoing development to the head of PD and the management team who’s responsibility is to allocate resources to projects

33. Case: Slipstream cont.Product strategy and portfolio mgmt • 2 products form the offering of the company • Basic video • Create and stream synchronised rich media presentations • Under evaluation is a product for mobile platforms • 30-day free demo download is offered via web, this includes free support for customers to set the product up • Main customer group is service providers sold directly by Slipstream (80% of total sales) and agents (20% respectively)

34. Case: Slipstream cont.Revenue logic • 80% of sales comes from licensing, maintenance fee (includes helpdesk support and all updates to the purchased product version) provides 20% of the total revenue • In-house development and some outsourced developers, the technical core was licensed from an outside research institute with small sharing of Slipstream’s sales • Total sales 2001 were 170 000€ and Slipstream was making a loss • In some cases customer-specific work, which is becoming more common in the future

35. Case: Slipstream cont. • Ad hoc marketing process start after the product release is finalised (after possible delays) “get it to the market as soon as possible” • Maintenance of old releases is handled by letting the customers download a new release from the web – this has been forced by the quality level of older releases • Project personnel responsible for new product release is sometimes forced to create service version of the older release in short notice

36. Case: Slipstream cont.Requirements management • Ideas for new features come from existing customers, sales & marketing, PD and company management & board. Important source is competitor surveillance • Product manager creates a requirements specification (RS) from the feature database and other sources • Based on the RS-document (some 20-50 pages) the project managers create functional specification documents, project plans and project breakdown documents • Product manager writes separate summaries for sales & marketing

37. Case: Slipstream cont.Requirements management • Focus changes • In weekly project meetings some change requests often surface • If something is to be left out the product manager must ask for the permission of sales or the management team to authorise them • More important changes must be taken to the management team for approval

38. Case: Slipstream cont.Perceived problems • Development roles and responsibilities are not sufficiently clear • The process for identifying the correct product mix and focus is not sufficiently clear • Requirements process is document-heavy • Severe problems in effort (feature) estimations causing projects to be delayed • Testing is not adequate

39. Case: Slipstream cont. • Suggestions made for Slipstream after assessing the situation: • More efficient requirements engineering process – reduce the amount of documentation • Enhance mechanisms for project tracking, effort estimation and product feature control • Improve testing practices • Others… • Initial feedback on suggestions was positive

40. Case: Slipstream cont. • Another interview was carried out 3 months later • Project and quality aspects had been improved since the initial session – therefore the situation looked promising • Much of the process development work was still clearly ahead

41. Case: Cielago • Founded in 2000, 15 employees of which 8 in PD, 4 in sales and 3 in management • Hardware and software development teams (2) • Products offer wireless short-range network capabilities to industrial applications (e.g. wireless meter reading, condition monitoring, wireless point-of-sales, etc) • Customers are perceived as OEM manufacturers, integrators and consultants • Customers are required to customise the product for 12-18 months to reach a working solution

42. Case: Cielago cont. • Sources of revenue are: customer-specific training, installation, and application development projects are a significant source of revenue. Some revenue is also coming from license sales • Relatively undeveloped process for software development and ad hoc-style resource allocation • R&D decides product features, the sales is not able to supply customer request information

43. Case: Cielago cont. • Suggestions made for Cielago after assessing the situation: • Improve communication between sales and R&D and develop cooperation processes between the departments • Introduce project progress tracking • Start defect tracking with some basic tool • Comments for suggestions: • R&D and sales communication is not working – development is driven by technology push (not market driven necessarily) • Full rethinking of the company process from idea to after sales is required with inputs, outputs, roles and responsibilities required

44. Case: Cielago cont. • Results after 4 months: • Altered roles of some key personnel to support interaction between R&D, sales and the customers • New productisation process and more rigorous specification and analysis of new product features • Head of R&D was appointed as the head of sales to ensure proper communication and information flow • Explicit and systematic process for analysing new product features allowed informed decision-making • A phased process for NPD had been introduced

45. Case: Cheops • Founded in 1996 with 100 employees of which 40 in PD, 40 in sales and marketing and 20 are divided in management, customer support and IT support • Offers performance measurement and process management tools for enhancing organisational strategies, objectives and business process improvement • Customers are large public and private organisations reached through direct sales and 100 retail partners • 2/3 of revenue comes from partners. 70% comes from licenses and 20% from maintenance contracts • Revenue 2001 was 12M€ and profit 3M€, PD costs were 15% of the revenue

46. Case: Cheops cont.Perceived problems • The PD-process needs to be improved and scaled up with more structure and control • Product focus in the future is unclear • Requirements management should be enhanced and feature value to customers is sometimes unclear • Automated product testing is not adequately used

47. Case: Cheops cont. • Initial suggestions: • Improve customer feedback mechanisms for product features • Product management and understanding where the product is going should be developed • Enhance requirement allocation for features with specified work amounts for each feature • Feedback on suggestions: • Overall positive

48. Case: Cheops cont. • Results after 5 months: • Requirements prioritisation was improved and feature requirements had become traceable • Production team responsibilities had been renewed • Some minor enhancements

49. Refining the framework based on theoretical and empirical findings • The original framework remained mostly the same. Under Organisation –decision area Outsourcing was added to reflect the significance found in 2 cases • Portfolio management –decision area did not experience any major changes, the naming was slightly altered to better reflect the issues • The area of Requirements did not change as a result of the empiria

50. Refining the framework based on theoretical and empirical findings cont. • In the area of Development strategy there were additions: Communication among team members, interaction to the customer interface / own organisation and concurrency of different development methods • Technology area was added with A common conceptual view of the structure of the product and involving stakeholders in making important design decisions • Quality strategy decision area was added with test timing, reporting, documentation, quality metrics and test planning