A few days ago I found Josh Elman’s article “Let’s talk about Product Management”. Hope you’ll check it and enjoy every single slide. He described the core functions of product manager and one of them is defining requirements.
I’ve read many articles about product management and entrepreneurship. Most of them are about a “feedback loop”, “how to say no”, “product/market fit” and many other topics. People don’t like to write about requirements because its boring. I don’t blame them. The only thing I can do is write my own article fully focused on the product requirements importance. I decided to use some slides from Mr. Elman’s deck. Hope he doesn’t mind:)
Let’s start from the core slide. This is what real product manager must work on. Do you see the “Define the requirements & Roadmap” in the left bottom of the slide? Good! As a product manager, you need to start from defining the problem and value proposition. Then you move to competitors research. Now you have enough information to specify your own solution. This is where product development starts from.
Think about product requirements as a reliable foundation of the entire process. Your team must have enough information to know what must be built. Help your team ship the right product to users.
Many startup guys say something like “… we build MVP so that we can test the concept. The very first version of the product can be pretty rough but that’s OK”. Hope you’ve read “The Lean Startup” and remember what do customers (not early adopters) think about “pretty rough” products.
But let’s get back to product requirements. You made a really great job defining the problem, market and value proposition. It will be very disappointing if all this work goes waste because the team did not build what you expected to see.
Any problem can be solved properly if the solution is clear for any person who takes part in the process.
A conversation-based product development frameworks can work well. But let’s keep in mind two things:- product managers have a lot of things to do - same words can mean different things to different people
A product requirements should be like a musical score — accurate and concise. If you were learning to play a song and have forgotten a fragment, you shouldn’t have to go to its author. Just get back to the score.
Well-defined requirements can save your product. I’m not joking :)REWORK is one of the biggest wastes in the software development and it’s not a secret. Rework can be a very “frequent guest” if you and your team do not have the common vision of what you’re building and how it should work. What would you prefer to spend money on: growth or rework and bugfixing? Take a deep breath and think about it.
Hope you enjoyed reading. Let me know in a comment.