Step-by-step guide to bootstrapping your new product development - Part 1, Principles

Endjin spend a lot of time working with start ups and businesses who are pivoting into new product areas. They are usually operating under fierce resource constraints, and this has an impact on the way in which they can approach their development program.

We've evolved a principles-based approach to the new product development process which can be applied to a wide variety of businesses. It's based on the MIT disciplined entrepreneurship approach, incorporating great tools like the Value Proposition Canvas and the Business Model Canvas.

In this series, we're going to look at an example of a "lean" new product development process, applying these principles, and looking at some of the caveats.

Part 1: Principles

What is a principles-based approach?

The process we're going to describe is a set of principles that can be applied to any product development programme – not a set of forms, procedures, data points, roles and responsibilities to be slavishly applied irrespective of circumstance.

You should be striving to understand and deliver on the spirit of these guidelines, not adhering rigidly to these rules.

As with all 'lean' processes, it is based on incrementally testing the market-fit of the proposition as cheaply as possible to increasing levels of confidence, with reducing levels of risk.

While we're thinking in terms of software-based products, the principles apply equally to all kinds of product, from data to widgets.

Lean doesn't mean 'start coding'

A common error when people look to implement a 'lean' product development process is to think that they should just leap in and write some code. A lot of start ups come to us at the point where they have been coding for a year or so, and have what they think is nearly their "minimum viable product": a huge hotch-potch of half-finished features, all of which look like pretty good ideas, but no feedback from real customers on what they'd actually use, and, more importantly, what they'd pay for. Our advice is always: "stop coding, start developing the proposition".

Why does this happen? It is a misunderstanding of lean/agile principles. Founders read that they should develop iteratively and incrementally. That they shouldn't be doing "big up-front planning" (the waterfall approach); that they should deliver to the customer early and often, and incorporate feedback as they go. All of that is true but...

Writing code is extremely expensive and is about the least lean thing you can do.

There are other alternatives such as mock-ups, wireframes, brochures, questionnaires, demos, videos - all of which can be delivered to the customer early and often, to gather feedback which can be incorporated into the product development process.

You should be looking to use techniques to reduce uncertainty and increase the chances of success, weeding out unworkable ideas as quickly and cheaply as possible.

Evidence based iteration

Fundamentally, the process we describe is methodical, evidence based, repeatable, disciplined, and cost-and-benefit focused.

At a high level, it is based on the classic lean build/measure/learn cycle.

Build

"Build" doesn't mean "start coding" either.

Before we get to real software, we might build paper models, slide shows, and brochures – whatever we need to test an "unknown" in our product concept, and help us to understand how we might bring it to market.

Most product ideas will not get even as far as building a software prototype – you will have made a no-go decision much earlier in the cycle. This is excellent – you've stopped wasting time and money!

Measure

Before each step in our process, we define metrics for a go/no go decision which will allow us to proceed to the next step. Sample metrics are provided throughout as guidelines.

Learn

After each step, we evaluate those metrics and make a go/no-go decision to proceed.

A no-go decision may be "stop", or it may actually be "go back to step x and iterate again" depending on the budget we have available.

A go decision will draw down on the budget for the next step from the overall Product Development budget.

The importance of business information

Accurate, unbiased business information is critical to success. Curiously, though, many people we talk to fear the overhead that collection and collation of accurate information entails far more than making existential business decisions on "a hunch"!

This does not disguise the fact that it is important to minimize the overhead involved in gathering data, to focus that information gathering on answering specific business questions, and not losing sight of the real business goals.

One way to achieve this is to avoid starting from a blank sheet of paper every time.

Business information generated by the product development process should be retained and curated, and made available throughout the organization, reducing the cost of going through this process for each product idea.

Some organizations (e.g. Reed.co.uk) make an executive responsible for the coordination and collation of this business information; even in a small organization, that's a good idea. The people responsible for collecting the data should also be chickens (in the ham-and-eggs "pigs and chickens" stakeholder model) - they should not have a stake in what the data shows (this can be tricky, and we'll look at structures that can support this in part 10).

The Process

We have divided the process up into 9 broad phases of product development, from inception through to end-of-life.

Within each section, we define a series of steps to go through to reach a go/no-go checkpoint. Those steps might be formally executed by a formal product team, or simply considered and noted by a person who is formulating an idea in their spare time.

The amount of time you spend on each step is determined by the complexity, risk, and expected investment required to get through the next step. We are trying to avoid spending money unnecessarily, and exposing ourselves to unquantified risk. But we don't want to get trapped in the 10,000 page business plan of analysis paralysis. At every stage, we're doing "just enough" to assure ourselves that we're all on the same page, and that we're not making a big, expensive mistake.

Subsequent stages will build on the learnings and evidence of previous stages, and we'll iterate (that's management speak for "do it over") if we run into a dead end.

Right from the get-go, we have a complete (but sketchy) picture of what we're doing. We gradually shade that sketch in more and more detail.

Avoid	Achieve

(If Gregory is not your cup of tea, there's a version of this metaphor involving an inventor of spread spectrum/frequency hopping technology, over here.)

The Gregory Peck metaphor is important in two ways. The more obvious angle is that it shows the value of a sketch, as opposed to 100% detail about a small piece. But it also shows that we are focusing on the important stuff. Gregory, eventually, gets sketched to photo-realistic quality. But the background around him remains blurry. We've emphasised the bits that help us to really understand our product. We've not ignored the background completely - we've sketched it sufficiently to understand where the boundaries lie, and to let us be confident that we can ignore it.

So, those are the underlying principles. In the next part, we'll look at product inception.