You don’t have time to NOT do product discovery (tales from a failed startup)
Have you spent weeks, months, or maybe years of your career building stuff that ended up failing? Maybe only 10% of what you spent all that time on was a success, the last 90% was never used? Don’t worry, you’re not alone.
Having a discovery track takes time. But after you see the light, you’ll realize that it’s just one of those things you’ll never want to be without again.
“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”
— Marty Cagan, Inspired: How To Create Products Customers Love
What is a discovery track? The discovery track is a “pipeline” next to your regular development track. Basically, Discovery is figuring out what to build, and the development track is actually building it.
Now let me start by telling you what happened to me before I discovered the joy of Discovery.
I founded and worked at a startup for 15 years. In the beginning, it felt easy. Almost every functionality I added to the product was something my customers wanted. I had a great intuition and I was extremely passionate about it, working almost 16 hours a day for years. When I did hit and miss, making features no one used, I simply made up for it by creating even more features. But most of the time I hit the bullseye, and the clients were extremely happy.
Sounds like I didn’t need Discovery, right?
Nope. The company grew, and things changed…
Now it wasn’t 80% bullseye development, but more like 60% — and the more employees we got, the more downwards we went.
We still had really happy clients. Mostly because we often did, even, big revisions for free, which my co-owner and I often took upon ourselves to do in the evenings.
Of course, this wasn’t sustainable. After a while, this really started to hurt, both financially and personally.
Sometimes I found myself blaming the employees. “Why didn’t they think of this obvious solution?” When in reality it was only obvious to me because of 15+ years of experience.
As it got worse, we started to question ourselves, and the clients. We started asking for tighter contracts and plans. Every time the client had a small revision, we’d go into defensive mode and say “It will cost more, and it will mean a delay.” And on top of that we were still so proud of our profession and work, that we ended up working for free anyway, while clients became less satisfied. Some clients said they missed the days when we were more flexible. They felt that we’d become “corporate”, so they might as well work with a company that was good at corporate (because, frankly, we sucked at it).
The best example was a big new SaaS project we spent a lot of manpower on. We were so sure it was going to be a success and practically sell itself. Because we wanted it to be perfect, the scope just kept growing. We ended up adding advanced functionality that, looking back, was enterprise functionality that most regular companies would never use. We even spent quite a bit of money on a nice video, marketing material, and a cool website advertising the product.
Then we launched it, and it fell flat. No one really needed it. People weren’t ready for that kind of product. We had a sales guy trying to sell it, and we didn’t manage to get one single customer before we had to scrap the idea and return to our core business again.
“Total Disaster”
-Trump
In hindsight, what our employees and we really needed, was a different kind of leadership and direction. We just hadn’t seen the light back then.
If 1 out of 5 of your projects are successful, imagine if you could eliminate the time spent on the other 4?
What we needed was a discovery track.
Looking back, it’s clear that the early days worked well because we actually had an unofficial ad hoc discovery process. When the company was small, we worked a lot with our clients. We talked to them almost every day, showed them progress, and without thinking about it, made small corrections along the way, continuously adjusting our projects.
Our approach ensured that our customers got exactly what they wanted, we didn’t have expensive backtracks, and we got “Heureka!” moments every day, which is just a great boost both professionally and personally.
So what is discovery?
Discovery is what comes before the MVP. Building things are expensive, so before spending time on delivery, we should validate that a demand even exists!
It’s important that you include the entire team in the process. Discovery requires participation from product management, product design, and engineering. If you leave people out you will not succeed.
A discovery sprint is a one week time-box of product discovery work, designed to tackle at least one substantial problem or risk in your product’s definition.
— Marty Cagan
Discovery is all about validating as fast as humanly possible. Basically broken down, discovery has 3 time-boxed parts:
- Inspiration
Inspiration is the phase where we, as fast as possible, learn the most about the problem we’re facing.
We talk to actual users, stakeholders, and whoever is important for the project to be a success.
During this phase we also observe users, write down their actions, figure out what problems they face and what they especially like. - Ideas
This is where the whole team pitches in. We sketch, write, paint, whatever is needed to convey ideas to each other.
During this phase, we generate and prioritize as many ideas as we possibly can in the shortest amount of time possible. This involves a lot of post-it notes.
This phase is so important! I can’t count the times when I entered a product discovery thinking I personally had already thought of all the good ideas, and then I was amazed by the good output that collectively came out of so little time. - Testing
Now we test to validate our ideas and test them out as fast as possible. This includes drawing on paper, building non-working prototypes in programs like Sketch or Axure and trying them out with real users.
This is how ideas get validated in the real world. We discover that maybe the product wasn’t needed, maybe it turned out to be confusing and it needs more time on the drawing board, or maybe it was just that idea you feel resonates with users and will turn out to be your new big feature that will drive your project forward.
What you need is to validate in a structured way.
In the failed project I mentioned earlier, we did talk to some potential clients.
But here’s the thing
just asking people if they would like something, is probably one of the worst way to validate something.
If you ask people in broad terms “Could you use a product that does X and Y?” then without doing actual user testing, it will be too unspecific a question, that they will fill in the blanks themselves. They will imagine the product as something that solves their specific pain points. And if you don’t discuss pricing, they will imagine something that might fit their exact budget (which is often on the low side).
When should I use product discovery?
You shouldn’t use product discovery for everything. That would be a waste of time. Product discovery is for finding a product market fit, solving complex problems, and creating great (and needed) product features in the least amount of time possible. It’s not suited for solving small tasks. Also, you shouldn’t use it for obvious things. If you already know the outcome, you’re not doing discovery.
Would you like to know more?
Now if you’re ready to go deeper into the actual process of discovery, well, that’s a subject of about a thousand more blog posts, which I’ll write more about in the future. If you need a great resource on the matter, and want to get started right now, I highly recommend reading The Sprint Book, but if you google “Product discovery” there are so many great resources out there.
You still don’t think you have enough time for discovery? See you in a few years when you’ve wasted 60% of your time and you’re ready to see the light!
Written by Martin Mouritzen.
Like this post? Please feel free to comment and click “ 👏” to help spread the word, and don’t forget to click “Follow” for more stories about discovery and product management.
