More Features != Better Product
One of our primary motivators for wanting to play an increased role in product strategy and design with our clients is that it is too easy to find ourselves being evaluated on the rate at which we deliver product features to the detriment of the product we are building. It’s natural that our clients approach us with this mindset, but it’s ultimately not in their best interest.
Simply put, more features does not equal a better product.
Don’t get me wrong – we’re great at organizing a team and process to efficiently crank through a backlog of features. We value this highly. But while an effective engineering team may be an important component of creating great products it has little to do with ensuring that the product itself provides real compelling value to its users.
A challenge for us today is figuring out how to grow the scope of our engagement to include a conversation and process for determining what we are building, why, and when it should happen.
Prototype for Validation, Learning and Empathy
Because our clients usually come to us with a product concept and an understanding of the problem that it solves, we have to jump right in with them. How they arrived at the problem definition and solution to that problem varies widely from bouncing their idea off friends and family to working with a web design firm to design thinking and market research practices. We’re usually not in a position where we can question the validity of the problem or even the effectiveness of the proposed solution. However, if we just start building, our first opportunity to validate the solution will be when we first put working software in users’ hands.
To date, we’ve focused on ruthless prioritization and early delivery of a Minimum Viable Product to get to the point where we can validate a product concept and get the necessary learning our client needs to steer the product. Our role in this process is to help our client find the core value proposition of their product and to define the smallest whole experience they can present to a user. This is still usually a conversation between developers and product owner.
What we want to add to the picture is far more empathy for the users of the product and opportunities to steer the product before investing significant time in building it. Given that we have a problem and proposed solution on the table, let’s figure out how to quickly validate that the solution solves a real problem. Let’s learn what works, what doesn’t and course correct before we invest heavily in building.
In Lean Startup terms, we have a hypothesis and need to construct an experiment to test that hypothesis. In Design Thinking terms, we are ready to prototype a solution to an identified problem statement. Our prototype will give us insight into the problem and our solution and will give us, the development team, greater empathy for our users.
That’s not to say that building can’t start, just that the implementation effort should be focused on creating the simplest thing that will give us the learning we need. For some experiments, real development work may be required. It’s likely though that we can come up with prototypes that are faster to create – from role playing scenarios to clickable screen shots.
We are starting a project next month where this is the plan. We have deliberately limited the size of the initial team so that there will not be pressure to put a team of developers to productive use right away. We’re going to take 3 weeks to create, test and iterate on as many prototypes as we can to steer the product definition to something we know is closer to meeting real customer needs. Our team will have greater intuitive understanding of the problem we are solving and empathy for the users of our product.
We hope that starting in this way will help to turn the focus of the engagement from building features to creating a better product and delivering true customer value.
