If you want to be a bad product manager, give your requirements to development without any explanation. Their job is just to build what you tell them to build — they don’t need to understand why. Any time you take telling them why the requirements are important is time taken away from actually building the product.
If you want to be a good product manager, articulate to development why requirements are important. Developers and engineers are not just order-takers but an important part of the product development team. In order for the requirements to be fulfilled, everyone needs to understand their purpose and value.
When there is common understanding of the “why” behind a requirement, those responsible for “how” the product can fulfill that requirement — designers, developers, etc. — can come up with the best possible solution. Without understanding the purpose of a requirement, teams will question whether it needs to be fulfilled, whether it needs to be changed, how valuable it is to the customer, and whether there isn’t some other better requirement to be working on.
Mike Lunt calls this The Other Side of Product Management. If one side is “gathering requirements and selling the products to the sales team,” then the other side is “selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group).” He adds that
for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).
There are actually many sides to product management, but this is one of the most important. Good product management requires the ability to understand customer and market needs, communicate them to the product development team, and package the solution as a compelling product for sale. Getting understanding within the team is the bridge that connects the market needs to the solution and end product.
So true – – product development are human beings who like to feel part of the solution, not just a clog in the wheel.
Allowing them to understand what the product is for and why will motivate them much more than just their core function. The PM must evangelise to the development team!
Great article, Jeff.
You’ve definitely nailed one of the two key dynamics – motivation. As you say, when people know why what they’re doing matters, they will be more motivated to do it (as long as you’re asking them to do the most important stuff).
The other affect comes from providing context. People simply operate more efficiently (less second-guessing, etc) when they understand the context in which they are working. Things like “this may not be the most important feature, but that use case is worth $10 million, and this feature is required for that use case.”
Great article – now stop covering your topics so effectively, so I can add to the conversation without just saying “go read Jeff’s thing.” Seriously, tho – good stuff, I enjoy reading it!
I have just written an article on my blog entitled “Product Management and Knowledge Sharingâ€. I touch developer/engineers working closely together so that requirements etc…can be fully understood. I also touch on Scrum – an agile development method – and how it may or may not aid in knowledge sharing – please have a read and let me know if you have had any positive of negative experience of Scrum (or any other agile process) aiding in bringing product managers, business users (e.g. sales, marketing and e-marketing) together and therefore foster knowledge sharing that results in cutting edge products and really cool features that generate revenue. I’ll be pleased to hear your thoughts and experiences.
I am looking for info on product requirements. If I want to sell a new type of UMBRELLA, what specific info needs to be on product and on product packaging?
So we are selling to sale and engineering. Could we market to them as well? Could we use a curriculum marketing campaign to sell them and continue to sell them on an ongoing manner?
How much of the product roadmap do you reveal, particularly when you are in a fast follower situation?
The product manager learns from the user, so the product doesn’t have to teach the user. But, the product manager has to turn around and teach engineering and sales. Teaching and selling are the same thing.