Transcript Document
SB Program 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 University of Jyväskylä SB Program 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) University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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? University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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) University of Jyväskylä SB Program 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.) University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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) University of Jyväskylä SB Program Different types of companies University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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) University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program Case: Slipstream Results 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 University of Jyväskylä SB Program 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 productrelated 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 University of Jyväskylä SB Program 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) University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 1218 months to reach a working solution University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program 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 University of Jyväskylä SB Program Decision area Contents Organisation (by whom, and where?) Organisational model, Roles and responsibilities, Team staffing, Team physical arrangement and location, Investments in team collaboration, Use of outsourcing Portfolio management (what and when?) For each product; Marketing (incl. Timing), Servicing (incl. deployment), Sales and distribution, Revenue logic, Release management; Operational (management; release process and configur. Mgmt) Strategic (planning; release contents, roles types and timing) Requirements (what and when, specifically?) Elicitation Specification Allocation Change management Development strategy (how?) Development model(s); for each: Type of dev. Process, Progress tracking and control, Communication mechanisms (within, customers, rest of org., Concurrency of development models Technology (by leveraging which technologies Product architecture (incl. Asset sharing, common conceptual view and design) and employed technologies. Development infrastructure Quality strategy (delivered with what emphasis?) Testing: types, timing, reporting, test documentation, quality metrics, test planning Risk management: Release criteria, release success evaluation University of Jyväskylä SB Program Thank You! Questions are welcome University of Jyväskylä