4. Software Product Roadmap and Launch Management

Software products are notorious for being late to market or quickly replaced with 2nd versions. In our experience that’s normally due to insufficient launch processes resulting in problems such as the following common examples:

  1. Market demand and target segment never correctly ascertained
  2. Front line teams not trained or have not planned for the product
  3. Happy pilots not acquired before wide-scale release

Also product launches take a significant amount of resource, there is a number that your organisation can cope with per year. Knowing this limit helps ensure you are only progressing with the most compelling ideas and you know when extra resource may be required to deliver on time.

Software Product Roadmap Management

Once you have a clear product scope and market segment, and all customer facing teams have been involved in the business case, launch planning can begin with appropriate stages for sign off, agreed actions, owners and timescales. Most importantly each department head must agree readiness for the product, this helps ensure the new product will strengthen your brand reputation rather than damage it.

The exact launch stages and actions required will vary within each organisation but, after development-team-led piloting, it’s advisable for operations to run pilots. Once all field testing is complete; ready to deploy, support and sell stages will include all of the key actions to achieve success.

It is also important to be able to look at the status of the whole road-map together because there will undoubtedly be some inter-dependencies and difficult decisions to make. Where possible non-partisan project managers can be much more effective at running launch projects across all teams. In addition to providing scope they bring cohesion and focus to product planning actions enabling product owners to focus on strategic and tactical management of their product.

The following generic example helps track the progress of each product against the agreed launch stages. You can also incorporate due date and the first year financial forecast in the product description if that helps prioritisation. This is intended to be used as a headline report to drill into the reasons for the current stage, risks, issues, late actions and consequences. We build all processes and charts in Excel initially to avoid system restrictions.

Software Product Launch Management

I believe a significant factor here is whether you market your impending product before launch or wait until full market readiness. Whilst I think it’s good to show interested clients your road-map, and have every confidence in doing so because your processes ensure you deliver products on time, I like the idea of waiting before unleashing the full marketing plan. This gives you the opportunity to control your marketing spend and pricing versus demand and increase resource in line with adoption.

Here are a couple of scenarios to illustrate the point:

Scenario 1 – Pre-launch Marketing

You spend a large majority of your marketing budget pre-launch. The product is launched on time and sells extremely well in the first 2 months, but you can’t actually deliver!

You have now taken a large amount of orders at a price you can’t change (in fact discounts have been given), you cannot recover any marketing costs and have to invest in urgent staff, which is much more expensive than developing a non-urgent staff training plan where you have enough people to get you through the initial phase. You also get to a level of usage quickly which reveals a volume related bug you can’t fix immediately.

So if the product is successful you end up with low customer satisfaction, damaging your brand and likely adoption of your next product, and lower margins.

If the product is unsuccessful you have incurred irretrievable costs.

Scenario 2 – Staggered marketing and monitoring

The potential alternative is that you spend around 50% of your initial budget around launch and keep a hawk eye on any discounting and demand at the initial price. Your fully trained early deployment staff are ready and the wide-scale top-up training plan is in place which will incorporate learning from the first installs. Early bugs go straight to the development team, who are poised to deal with them post launch, and fix them before the next implementation. The remaining customers in the backlog are never affected by it. You reduce paid marketing activity and the sales team use strong case studies to gain further wins.

This success also means you can increase price or remove early offers and handle discount objections knowing that 1. The benefits of solving the problem and 2. You provide a proven method specifically for customers like them.


3. Software Concept Analysis and Risk Assessment

We break this area in to 3 crucial topics to efficiently form a meaningful business case. These are geared towards significant new offerings but the principles should also be used to ensure all discretionary development is commercially focussed. The areas are:

  1. • Profiling & evidence gathering
  2. • Pricing & sales forecasting
  3. • Cost & consequences analysis

1. Profiling & Evidence Gathering

In our last post we discussed how the following 3 questions can go a long way to helping you segment markets:

Who are they (exactly)?

What do they buy?

Why buy from you?

By answering these questions you are able to find and size target markets effectively.

We also believe Porter’s five forces (Porter, M, Competitive Strategy, 1980) are still relevant today, which will help in your work here. Porter said “the key to growth, even survival is to stake out a position where you can defend yourself against head-to-head attack”. We have seen the consequences of new products taking companies in to dangerous spaces already crowded with specialists. Porter’s model is particularly powerful for reminding us that competitors alone are not our competition; substitutes and new entrants should also be swot analysed. Our 3 questions cover this topic in a easy-to-comprehend way.

But what happens when a number of options are available that all seem to have commercial viability?

Well, first, it’s really important that ideas are evaluated alongside alternatives. In isolation most ideas can look good, but I believe most apparently good ideas are loss making. Your development projects have to be the best use of your resources against the alternatives.

Therefore the next step, beyond the 3 profiling questions, is to gain EVIDENCE of the following:

a. Urgent demand to solve the problem.

b. Value attribution to the specific way (features, dependencies etc..) your proposition solves the problem.

This will involve collaborating with existing users and prospects, by interview, user groups, surveys or whatever means you use to capture the voice of customers. You may need to offer perks but it’s vital to formulate and ask the right questions.

Obviously customers find it difficult to say ‘no’ to any given functionality and suppliers find it difficult to ask how much they could charge. You can’t ask in terms of functionality but the problems they face and if solving each one is important. You may need to ascertain whether high functionality is more important than elegance conceptually. Beyond that we have used Kano analysis to help make specific Feature decisions. It taps in to the emotional responses when something is ‘in’ or ‘left out’ of the product.

2. Pricing & Sales Forecasting

The information you now have will identify clear value attribution to the specific way you propose to solve the problem. You can identify the costs of not using your solution and the differentiated value within the competitive landscape. You also now know the size of the segment you are aiming for and can make realistic sales forecasts. Why will they buy from you? Does the product fit comfortably with your overall strategy and does your brand convey expertise in the exact area you are selling to. It’s a shortcut to sales if yes and a longer term uphill battle if no.

You may need to devise pricing models around the financial circumstances of your clients alongside your own cash-flow pressures. This will help you decide between longer term recurring income, with lower barrier to entry, versus higher upfront costs. Pricing must fully realise the value you provide and be commercially appealing versus the alternatives. Total cost of ownership calculators are useful for showing tangible results but it’s only relevant compared to alternatives rather than comparing the worst scenario with your solution.

3. Cost & Consequence Analysis

True analysis of cost & consequences are often neglected in the software business. However they can easily be built into an objective risk assessment which goes a long way to correctly identifying the obstacles you will need to overcome.

Here’s an example output of a generic risk assessment, each category here had 2-4 questions which contribute to the score. Whilst the score is useful when comparing ideas with similar potential revenues, the main benefits are gained from this process being a standard part of your practices.  Put simply it sanity checks vanity projects.

The information gained from researching these 3 areas will enable you to create a meaningful business case. The process becomes quicker over time because you establish a fact base and product managers become accustomed to considering these factors at the idea stage.

This is extremely significant as you dilute your specialisms and potentially try to make your teams overnight experts competing with new specialist competitors; i.e. a position they cannot defend. Analyse an incumbent; does it take them 30 FTE’s to do it well, is the pay rate £100k pa or £25k for their specialist expertise? Plan the true costs of replicating their expertise.

5. In-Life Product Management

This stage is where you see the true return on investment from following methodical evaluation and launch processes. You now get to see the product perform as you expected or are able to articulate any differences in a meaningful way.  The resulting analysis is a key product management performance indicator.

My view on this area of collaboration is similar to my view on customer satisfaction in general. Assuming you ask customers for feedback, the question is whether you gather any feedback from your teams regarding customer performance with specific products. For instance, has the resource to install and support the product been as expected? What has arisen after multiple deployments? What could be revised to improve customer performance etc… They are actually more likely to answer on the finer detail at this stage than customers, who are normally either happy, or not.

Win/loss Analysis

Product management and sales should be working closely together ensuring every sales cycle outcome is analysed for its key factors.  These can then be broken into themes to guide next steps.  Here are some examples of levers at the early stages of win/loss analysis when underlying information may be sparce:

  • Poor sales ratio levers: review internal training, accuracy of demand, competition and segmentation research, marketing plan
  • High sales/low discount: review price and marketing strategy
  • Poor deployment performance levers: review internal training & documentation, adoption curve and staff turnover
  • Poor price performance levers: review sales training in full value of proposition, review accuracy of demand, competition and segmentation research
  • Poor software performance levers: review sales training to set the correct expectancy, level of field testing, technology stability versus qa standards, 3rd party integration issues.

Development Request Management

The staggered marketing and adoption approach discussed in Blog 4 also helps you make wise enhancement choices rather than responding to early, unhappy customer threats if you don’t develop what they are demanding.

If the enhancement is not commercially viable you are in a much stronger position to decline, as long as you explain the process and how you evaluate requests.  Strong brands can do this because of the diligence that has led up to this point and the fact that an intelligent product management methodology exists.

There are also some great guiding principles here which could be considered as product management best practice.  They are really checkpoints before you invest time fully defining and delivering developments:

  1. Is the request in a universal format with relevant questions answered including value of the change?
  2. Have support staff agreed that there is no suitable alternative within the product?
  3. Has a commercial person agreed the change offers incremental wide-scale value?

If the answer is yes to all 3 of these questions now is the time to find evidence of similar requests and gain a high level development indication, then  the concept evaluation process (blog post 1) can begin.

Later in life

The importance of win/loss analysis does not diminish over time as new competitors and new technology will appear and trained staff will leave. You need to know as soon as the former effects your performance, if not before, and you or your technical teams should be constantly analysing the latest technical possibilities.

Depending on the specific factors within your market, such as degree of bespoke systems, you may wish to adopt later life-cycle phases as follows:

  • Twilight – New developments are not added, compatibility with new operating systems not guaranteed
  • Legacy – All above plus support resolution is not guaranteed

When the time comes for you to take action because of any of the factors above, there are some simple golden rules which help:

  • If you are ending a product always outline an alternative and why
  • If you are exiting from the category or market segment, but want to maintain your brand reputation, why not devise an ITT for your customers and potentially even do some supplier validation work for them in advance and see if you can gain some preferred terms for them.
  • If you are moving all customers from numerous old versions to a single platform, be honest, share how your organisation will be more efficient and robust and the benefits for them.

In-life management is part of the fundamentals of product management.  If your portfolio was launched through processes similar to those in our blogs, the win/loss analysis is just the next stage of the process. If that’s not the case you can start by inviting feedback from internal teams on the existing portfolio in a defined way. Essentially you need to know the following things:

When we sell product X, this happens (i.e. nobody can install & support it like experts anymore) and the consequences are this (i.e. consultancy overspend, customer pain, cancellations, brand damaged, compensation given etc…), possible resolutions include (training investment versus remove product and focus on those aligned with core competences).

Once you combine the feedback with sales history you will quickly be able to evaluate pain versus revenue enabling you to remove, refine, re-train or replace.