Viewing entries tagged with 'product discovery'
Most people by now have read Marc Andreessen’s Why Software Is Eating The World. This was written back in 2011, and I’ve been watching his predictions play out in companies all around the world. While my focus is primarily on technology-powered software products, services and devices, I’m also very interested to find other industries where the techniques of modern product are used to disrupt their spaces.
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.