A few months ago I retweeted an article that explained how to avoid problems during the definition and development of your (primarily) technological products.
This was a good piece, but didn’t specifically describe the basic methodology for how to successfully define such a product. So, let me rectify that by offering the relevant, proven solid specifics, below. It is universally relevant for most product-types.
Today, many teams become distracted and fall prey to product definition problems largely attributable to the lack of fidelity in their execution. However, the process for getting things defined correctly can be quite simple. It’s well proven and fundamentally failsafe.
To get things right all you need to do is follow this Six Part Process:
- Find Lead Customers
Clients must be credible and linked to you be able to leveraging them into credible and likely downstream purchases. There will typically be 3-6 companies you approach and they should preferably represent the practical application breath your end-product needs to serve.
Avoid engagements where customers may borrow your ideas for repurposing internally or with other suppliers. Great trust and sharing of future plans is typically required bilaterally with these people, who are to review, comment upon and add real value to your Spec.
- Offer your Trial Product Spec as you go
To get audiences with clients you have to bring something complete and credible to the table; basically, this must be your Spec or a prototype. This offering is a supplement to an (ideally) already existing, meaningful relationship you have with the Lead Client which is based upon trust and prior shared experiences.
Work jointly with the first customer to tune-up your spec; ensure that Must Have and Nice To Have needs are incorporated (or, put aside) appropriately. Update the spec accordingly and move to the next lead customer on your list.
- Correct the Spec as you proceed
The spec will evolve and (likely) grow as you complete your first pass by these clients. Update and adjust as required, always minimizing additions and identifying Wants, Likes and REAL Needs as they deserve.
- Beware of building a Battleship or designing a Camel
As you cycle by clients, from time to time you must stop and carefully review the current Spec. Is it becoming unnecessarily bloated and/or distorted by less important content? Are you losing sight of customer needs, becoming overly focused on the technology?
Brutally cut back Specs so they contain just those features that define a compelling product with which desired Lead Customers will hungrily engage.
Be certain all content remains in the Spec that ensures hooks are included to extend in future directions which will or might be required. Don’t overestimate here, but also don’t architect something that cannot evolve, or will need major rework for future development(s). Do not build your product on sand.
- Re-circle the Lead Guys and Confirm
When the Spec is trimmed down to a lean offering that you believe will grab interest and secure Lead Customer engagement, you can then make a final pass at those customer contacts. Double-check these clients are still bought-in and voice real commitment to your final version. Ensure their needs for ease-of-use and functionality are all satisfied as required and when needed.
- Implement On-Time and As Specified
This is easy to say and harder to accomplish. Ideally, you should deliver exactly as promised. Commit to availability of what will satisfy Lead Clients’ essential requirements and to delivery by when it must arrive.
And never forget. When the product goes through Beta Tests you must have all the support available that will be required to overcome inevitable problems and make users feel safe.
When you’re speaking to clients and asking questions, heed the following warning. I have personally met clients that when faced with a what do you need question often fall back (through lack of their knowledge in your space) to a what have you got response, when queried about product requirements. Circumvent this dilemma by unearthing what they’re trying to accomplish with their own work and thus determine how your product can assist and empower them in reaching these objectives.
I have seen many developers flounder when interpreting unclear customer needs. This is often caused by either their own inability to truly understand the customer’s products (and thus needs) and usage, or by personal indecisiveness. Don’t let your team fall into either of these holes.
Let me offer a closing note of opportunity. Clients often find surprising, innovative means to use and adapt your products in ways that you may not have anticipated at the outset. Keep your eyes open early on for signs of such ideas as they often lead to killer features you can include.
So, if you’re looking to bring innovative, leadership products to market, try this process.
It works. It’s proven. Check it out and watch your market-driven products take off!
Ian R. Mackintosh is the author of Empower Your Inner Manager Twitter @ianrmackintosh