Viewing entries tagged with 'product discovery'
There is a very common fallacy about developers in our industry, and I think it hurts countless companies.
Exactly a year ago I was invited to give a keynote at the Craft Conference in Budapest and I discussed the 10 biggest reasons why product teams fail. You can watch that talk here, or read the narrative article here.
In my last article on Discovery Sprints I mentioned the concept of Discovery Coaches and several people asked me about that, so I thought I’d describe more about what this role is and when it’s helpful.
I find that many teams, especially those new to modern product techniques, are looking for a structured introduction to modern product discovery. In this article, I’d like to describe the concept of a discovery sprint, and also introduce you to a new book that goes into depth on this technique.
Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems in order to power these solutions. As such, for most teams there are two very significant challenges to tackle:
One of the tenets of Product Discovery, Lean UX and Lean Startup methodology in general, is to try and avoid or reduce waste. Mostly that means tackling the situation where we design, build, test and deploy a solution that fails to meet its objectives. However, in this article I wanted to focus on another form of waste, one I find particularly frustrating, one that I’ve seen in countless teams, and one that I believe is completely avoidable.
Much has been written about how to do product discovery in startups, by me and many other people. There are many challenges for startups, most importantly, survival. But one of the real advantages from a product point of view is that there’s no legacy to drag along, there’s no revenue to preserve, and there’s no reputation to safeguard. This allows us to move very quickly and take significant risks without much downside.
When I start working with product teams, one of the first things I try to do is to get them to stop thinking of their job as one of gathering and documenting requirements. In fact, I try to get them to stop thinking in terms of requirements at all. Most requirements are not actually requirements, and the rest are better thought of as constraints.
One of the things I like about a Lean Canvas is it helps to quickly highlight the key assumptions and major risks facing a startup or a significant new product in an existing business. This is a good thing. The idea is to tackle the biggest risks first. That's the theory at least.
Our job in the product organization is to create products that can sustain a business. Make no mistake about it: everything depends on strong products.