I believe there are two and a half ways to start to develop a product:
1. Big bang visioning.
2. Client led development.
3. Bit of both. Middle out strategy.
The article spends time exploring these, and will describe the benefits and pitfalls of the approaches. The end of each sub-section will describe ways in which you can dramatically increase your chances of success with all approaches. Note, that in all cases it is essential that you build a product that people want to buy. This is also discussed in this section and in future articles, particularly about your first customer.
It is conceivable that you might build a product that happens to coincide with customer requirements. It is even conceivable that you can build a new product which fills a latent requirement that your customer does not know they have. However, in both cases the product must deliver real, tangible and measurable value to you customer. So you need to be able to describe and quantify your products benefits no matter which route you take. This will be used directly and shape your customer acquisition strategies.
I would suggest that you involve your developers in this stage as much as possible. Developers may conceive of the product much more from a technical standpoint than a solutions perspective. So, agree a common language and have everyone focus on benefits to the customer, which in many cases will be your 'customers customer'.
Once you have agreed what the benefits are, write them down. Think about the value these will have to your customer and attempt to quantify this. If you can do this you will be well positioned when it comes to your pricing strategy. Make sure this list is reviewed regularly and new member to the team are exposed to the thinking, they may well have inputs that may change your approach.
A good tactic at this point is to build a sales deck in powerpoint as if you were going to do a sales presentation. Run through the deck and ask yourself do you think the benefits of your approach feel real, if not you should not build anything until it does stack up.
Let me say from the outset that I believe this to be the most dangerous route for any new product. However, it will work for next releases or extensions of an existing product and we will speak to this a little later.
To build a product, from scratch with no existing client, has huge amount of difficulty. There is no way of testing if the product will be successful. In addition, if this innovation takes place within an existing business with scale then it becomes even harder again as internal politics will slow things down. The reported failure rates on such ventures are extremely high (over 98%), so what is the problem.
The main problem stems from a lack of feedback and steerage, from a customers perspective. Without this, and without access to subject matter experts, your development team will start guessing. In general, my observation is that developers are lousy a guessing customer benefits. It will also be challenged by the management team. They will, probably not have a sales forecast (with real customers names in it) and will get nervous about project spend, as there is no balancing revenue focussed. Therefore, the project may get pulled. This often happens.
However, if you are going down this route, may I suggest the following actions might increase your chances of success.
How to checklist:
1. Establish a list of the high level goals of the product (i.e. environment it will work in, what type of integration it will have, what the development tools and method will be etc.)
2. Build a sand box and set a small team into a play and display mode. Their job is to build demonstrable assets, not resalable ones. Make sure a graphic designer is part of the team. Steering group – Exec sponsor, tech lead, marketing, sales and design.
3. Recruit a first client/beta customer.
4. Give the product a name, spend time on this and think about the downstream brand asset.
5. Establish a challenging delivery date, important to get team into right level of excitement.
6. Hold back some features (i.e. performance, GUI) to be delivered to project to get you out of potential ‘end of honeymoon phase’.
7. Get the users from the client team involved in feedback. Act on their feedback and reward them. You will want champions and references for your next client.
In short, focus. It is very hard to maintain a delivery timetable and prioritisation of functions without feedback. A client is a great way of achieving this. So, if you do decide to build a product from scratch without a client ensure your mission has one planned in very early on your journey. Even so, if you start building without a real customer in mind be sure your team’s works in a research mode at this point. A research mode should be a rapid build phase to produce tangible assets. These assets should be targeted for use in the client recruitment process. They should also be thrown away one the client has been found. It is really important that you do work with a throw away attitude at this stage. If you do not do this then your team will either be too cautious or too engineer orientated.
It is quite common for product to emerge from project work. It’s a good way to start. You will probably have been paid to build it. You will be able to use them customer as a reference and you will have access to domain expertise in the area you are building a solution for. It’s a great way to start but there are a number of pitfalls you need to avoid if you want to build a scalable, sellable product. The main issue is that the end result becomes more like a project than a product. This will be unavoidable unless you have sat down beforehand and worked out what you want to achieve.
I believe this strategy has the best chance of success.
In this strategy, we conduct some blue sky research with a client led project. Note this is different from taking a client led project and turning it into a product (as many will attempt to do). This has some real design goals and outcomes established at the start which are related to an ongoing business and not just a project. This has a better chance of success because:
· Real deadlines will be set
· Real feedback will be given
· Real money can be made (hopefully)
· The product will be better engineered
· Product management can start before coding!
· It is easier to align the ongoing company behind the product and sell its vision.
It should be built into the strategy, of the product, that a beta customer will be found before the project begins. It is not important to identify who the customer is at this stage. However, it is important that we understand that this customer will be very important to ongoing success of the product. So, whilst you don’t need to know who they are exactly, you should have an idea of what ‘good’ looks like. You should have this idea before you even start looking for the beta customer. Why?
Well, if you consider that at the beginning of your product development you will probably be asking someone in the beta organisation to take a risk. If this is a large organisation, then you need to understand that most of the time people tend to keep their heads down where this decision is concerned. So, what do you need to have in place to get them to agree to work with you? The simple answer is ‘Value’ (not just value proposition). So, you need to have an offering which has a value which is greater than the perceived risk. How do you achieve this?
· Have strong relationships in the client site. (Likeable – core values etc.)
· Integrity. You need to be able to demonstrate trust (a delivery record will help here, i.e. you have serviced them before).
· Proof of working, a demonstration product is great here.
· Take a financial risk. It’s ideal if they have nothing to lose, perhaps you could establish at risk/reward deal which pays you later.
· Form a partnership. Trade cost etc. for downstream references.
· Entertain your client, take them out, and get to know them.
The Take Away
The main thing that you should understand about your product strategy is:
'You have to have one !'.
I know that sounds obvious, but have you taken time out of the business to think about the product you are building. Have you written it down. Or, have you carried on with a series of conversations after meetings and in the pub.
If you don't take time, no matter how you start, to plan out your product your chances of success will be limited. So, the take away is..........da da da (as in the Croods - go see it) - 'failing to prepare - is preparing to fail'. Heard that one before ?
So, my advice to you is.
Write down what the benefits to your customer are going to be.
Quantify them as much as possible.
Enlist a beta customer and act on their feedback.
Have a strategy for your company and know where the product plays in that strategy ('see the article Stop !).