Don’t get me wrong. This post is not about a fight between development and product management. Product and Technology actually walk hand-in-hand and rely on each other.
It is about an unfortunately recurring reason why start-ups fail to grow, or even survive.
It is about making sure that you have the right discussion at the right moment.
An invention may not sell itself
At the origin of a start-up, you often find a great technological idea. Potentially even already patented. The inventor probably has an extensive background in the corresponding technical domain. And the truth is: anyone with the same background will get the point in the blink of an eye.
Now most of the time, people with the money to buy or invest in the technology will either refuse to spend more than 2 minutes trying to understand what you are talking about, or will raise expectations that will lead your potential relationship to failure.
My previous blog post on Product Pitching already gives some hints and ideas on how to communicate around your awesome technology. But as long as you call it a technology, not a product or service, you probably have a long way ahead of you.
Here are a few steps that can get you started:
1. Solve a user’s problem
A technology is not something you can sell. It is something that you can use as a leverage to solve a user problem. Finding what that problem is, is your top priority. You might end up figuring out that it will take more than your core technology to actually package a solution which the user will be ready to pay for.
Starting working out user personae. Try to describe your archetype user, their environment, personality, personal and professional objectives. And of course the problems they encounters, and that your product will solve.
Find some people matching those personae, and interview them. Be careful though: a user often ends-up telling you what features they expect out of your product, instead on focusing on their problems description. You must be in control of your product features and roadmap, and you can often stick to small adjustments or better document your product even for the strangest requests.
Then work out buyer personae. Those are too often forgotten. They may be very different from the user personae, though on the critical path for you to sell. They have their own problems and concerns, and you can’t work around it. You’ll want to identify them very early. If your product has a “wow” effect, you might even like to involve them in early stage demos. That always helps in convincing them.
2. Find your Market, and focus on it
You’re not going to solve everybody’s problems. At least not from the start. Think big, start small, go fast.
Every change in direction may cost you a lot, both in technology (re)development and market visibility.
Try to write the market vision. It should go beyond your product, which should support that vision and help getting there. In one sentence, you’ll basically need to write a description of your ideal world.
Then, within that vision, figure out who will be the early adopters. That is, the guys who will be the easiest to convince, and who’ll be willing to tell other about how great your product is. And don’t forget that this kind of communication has a great value. It may be worth finding a win-win arrangement with them, and give them a discount if that can promote their adoption.
Note that it doesn’t mean that you should build the product specifically for those guys. You should always keep the bigger picture in your head.
Oh, and there’s very few success stories like WhatsApp or Facebook. So try to avoid having early adopters that will never be willing to pay.
3. Build a roadmap
Well actually, now that your product vision is getting clearer, you will first have to focus on your MVP (Minimum Viable Product).
Imagine your ideal product. Now strip it from everything that does not directly contribute to solving the user problem, one feature at a time. Not that you’ll never have them, you’ll just have to lower the priority. And some more priorities might actually pop up meanwhile.
Now that you have your MVP, figure out the dependencies between your features. You want to figure out a sequential development cycle.
For that last part, some Agile Methodology basics may be useful. I do like how Scrum helps to shape Epics and User stories. Why? Because the formal way of writing a user story requires a level of abstraction which will keep you off thinking implementation. And thereby, you can assess all over your development cycle:
- Are there other ways than my technology to solve the problem? Or even just simpler ways?
- Can I find an “MVP” out of that MVP feature?
Remember not to get into over-engineering. The make or buy trade-off is crucial. Most of the time, you’d better integrate your product with Third Parties’, whose job is to focus on creating added value on topics which are not of your direct concern. For instance, if you’re building a SaaS application with on-line sales, don’t rush into build your own billing/invoicing system. There are some great apps for that out here, maintained by and evolving in the hands of guys who are here to solve your problem of online payments. Doing it yourself may cost you a lot more than paying transaction fees.
Last but not least, list your business objectives, and make them SMART. And synchronize your roadmap with it. That might require some more downsizing of the MVP.
From that on, monitor each new idea and initiative and figure out how it supports your overall strategy and business objectives. No need to waste time and imagine the how before you control the what, why, and when.
4. Get help, and get your organization ready
Of course, since the start of this blog post, I’m assuming that you intend to develop your own business.
If you wish to do so, the faster you realize your own personal strengths and weaknesses, the faster you will be able to find the team who will complement you. How large and diverse the team is will of course depend on what you can offer them, and for how long.
I guess there is no perfect model of a team, as it will anyhow depend on everyone’s skills. But never leave out or underestimate the basics. You will need sales, marketing, project management. Of course, having a Product Manager synchronizing all of that for you is a plus 😉 . You will need to listen to them and trust them in helping you to lead your product to success.
Never wait too long for sales to come in. The pressure and chaos they may bring in is worthwhile, as it will always challenge you into find how to make money, fast.
On the contrary, don’t get investment in too early. An investor most of the time buys a specific business plan. Drifting away from it, even for good reasons, may lead to counter-productive situations. So if you’re not yet 100% of where you want to go and how to get there, and/or if you’re not ready to make sacrifices on your vision, get that settled first.
5. Eat your own dog food
This could have been the first step. I’m ending this post with it, because it’s one of the most important.
“Eat your own dog food” is probably a quote you’ve already heard of. But I’d go further, saying “be a dog yourself”. How can you pretend that a dog is going to like your food if you don’t know what it is to run around naked all day long, sleep on a carpet and fetch that ball? Doing all that probably makes you want some special meal as a reward…
The best way of understanding your user’s problems is to experience it yourself. And so it goes for the solution you offer them.
If you can’t use your product, for whichever reason, then they probably be stuck the same way.
And if you’re putting yourself in a better situation than your clients, you probably don’t believe in your own market potential. Or you just have too much money to spend, which will backfire on you some time.
Running through those steps is probably just the beginning. But doing it right may considerably change the way you see things.
4 thoughts on “Product vs Technology”