SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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)
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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?
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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)
SB Program
University of Jyväskylä
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.)
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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)
SB Program
University of Jyväskylä
Different types of companies
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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)
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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)
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
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
SB Program
University of Jyväskylä
Decision area ContentsOrganisation
(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
SB Program
University of Jyväskylä
Thank You!
Questions are welcome