Viewing entries tagged with 'product discovery'
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.
This article is a little bit different, but if you make it to the last paragraph, I'm hoping it will help better explain where I'm coming from.
I'm always badgering teams about moving faster. Yet I continue to meet people and teams that not only move very slow, they don't understand the relationship between speed and innovation, or speed and quality. In fact, many people still think those goals are at odds. I attribute this mainly to a deeply rooted Waterfall mindset.
People approach creating products from many different perspectives. Some seek out customer pain and dedicate themselves to solving their problems. Others follow the technology and strive to deliver solutions that are just now possible. Some like to follow competitors and deliver better solutions in a fast-follower model. Others are simply trying to find a way to make some money so that they can sustain their business.
Every week I continue to find product teams laboring away on old-style product roadmaps that have been painstakingly negotiated with management and stakeholders, sometimes for several quarters in advance. I have written several times about the problems with this approach and why it so seldom results in the business impact that the organization was hoping for (see The Opportunity Backlog and Product Roadmaps).
The past several articles have discussed the nature of Continuous Discovery and Dual-Track Agile. In this article I'd like to discuss another dimension of working effectively in an Agile environment, which is how we manage commitments.