Product Strategy Decisions in Small Software Product Businesses A Framework and Experiences - PowerPoint PPT Presentation

1 / 52
About This Presentation

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


Helsinki University of Technology. Edited by Rauli K ppi, Software Business Program ... must ask for the permission of sales or the management team to authorise them ... – PowerPoint PPT presentation

Number of Views:28
Avg rating:3.0/5.0
Slides: 53
Provided by: jonnak6


Transcript and Presenter's Notes

Title: Product Strategy Decisions in Small Software Product Businesses A Framework and Experiences

Product Strategy Decisions in Small Software
Product Businesses A Framework and Experiences
  • Submitted on 8.1.2003
  • Jarno Vähäniittys masters thesis
  • Helsinki University of Technology
  • Edited by Rauli Käppi, Software Business Program

  • Product strategy has been identified as the most
    important management area of software product
  • 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
    companys product development to its business
    strategy (McGrath, Anthony Shapiro 1996)

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 personnels opinions than
    systematic decision making process and fully
    informed decision makers

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

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?

  • 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

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

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

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

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

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

Common problems in New Product Development (NPD)
  • Failure to invest in current and future core
  • 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

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

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

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

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)

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

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

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

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)

Different types of companies
Characteristics of product business
  • Amount of customer-specific effort is typically
  • 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

Characteristics of product business cont.
  • Feature elicitation and valuation are based on
    dynamic criteria and in-house domain experts
  • 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
  • Pressures from time-to-market and increasingly
    shortened release cycles

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

Characteristics of small companies and managerial
  • 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

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

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)

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

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

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

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

Case Slipstream cont.Roles and responsibilities
  • Product managers are responsible for the feature
    set to be implemented in the project and end-user
  • 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
  • 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 whos
    responsibility is to allocate resources to

Case Slipstream cont.Product strategy and
portfolio mgmt
  • 2 products form the offering of the company
  • Basic video
  • Create and stream synchronised rich media
  • Under evaluation is a product for mobile
  • 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)

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 Slipstreams 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

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

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
  • Product manager writes separate summaries for
    sales marketing

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

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

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

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

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

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
  • Relatively undeveloped process for software
    development and ad hoc-style resource allocation
  • RD decides product features, the sales is not
    able to supply customer request information

Case Cielago cont.
  • Suggestions made for Cielago after assessing the
  • Improve communication between sales and RD and
    develop cooperation processes between the
  • Introduce project progress tracking
  • Start defect tracking with some basic tool
  • Comments for suggestions
  • RD 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

Case Cielago cont.
  • Results after 4 months
  • Altered roles of some key personnel to support
    interaction between RD, sales and the customers
  • New productisation process and more rigorous
    specification and analysis of new product
  • Head of RD 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

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
  • 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

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

Case Cheops cont.
  • Initial suggestions
  • Improve customer feedback mechanisms for product
  • 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

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

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
  • 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

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

(No Transcript)
Thank You!
  • Questions are welcome ?
Write a Comment
User Comments (0)