product strategy decisions in small software product businesses – a framework and experiences

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Different types of companies

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

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

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

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

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

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)

SB Program



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



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


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


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


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



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



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



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



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



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



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



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



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


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


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


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


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


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


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


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


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


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


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


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?)

ElicitationSpecificationAllocationChange 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 planningRisk management: Release criteria, release success evaluation

SB Program


Thank You!

Questions are welcome

product strategy decisions in small software product businesses – a framework and experiences

Documents