Product managers and developers don't practice collaboration. Instead, they toss documents back and forth, trying to anticipate objections in advance. Sound familiar?
In more than one case, developers have complained that product managers’ requirements were not detailed enough. (And they usually aren't). Product managers complain developers wanted specifications. (And they usually do.)
They were both wrong.
What's needed is a story-writing workshop. Gather your product managers, designers, and developers together to write stories. As a team. What you’ll find is team members challenge one another and will get to a common understanding of what’s needed and what’s not.
A launch team said, “We need to know what features will ship in the next 12 months.” Haha. The product management team is wondering what will be completed in the next 12 days!
For many teams these days, it seems the developers have gone agile but no one else has.
Bring the launch team members together to discuss what they need to know (and why) and compare that to what the product team can know. It’s generally best to launch on a predictable schedule, regardless of whether you’re releasing new capabilities continually or periodically. The marketing team may want to know what capabilities will need to have a video demo but—even if they don’t know the details—they at least know they want to have one or more videos. So plan the videos for topics yet to be determined.
The launch team meeting can rally around a date and an as-yet-undetermined set of capabilities. As the launch date approaches, more is completed. More is known. The details can be filled in when they’re ready.
Don’t just write something and throw it over the wall. Let every document, story, ticket, or template be an invitation to a conversation. Create working documents and templates that are written together. Explain and document areas that cause confusion.
The key to teamwork is collaboration
Here are some common product templates that are better when written by a team.
Product Canvas. What is it? Who is it for? Why would they want it? Why is it better or different? Every team needs this basic definition of each product. It’s a one-page document that summarizes the business and market aspects of a product. And it should be shared with every team: executives, design, development, marketing, sales, support, and services. Everyone.
Product Roadmap. What is planned now? and what is planned next?
The roadmap is perhaps the document most frequently requested from product management. And it’s almost universally misunderstood.
A product roadmap shows the intended path from your current state to your future state with rough estimates of when the work will begin and end. And all dates and times are subject to change without notice.
Go to a mapping program and ask how to reach a destination. It gives you a few options—one way is faster, but the other way has fewer turns. It will tell you to take this street, turn onto that one, and then get on a certain highway. It also tells you when you’ll arrive—if you leave now and nothing changes. All dates and times are subject to change without notice.
The best roadmaps are created in collaboration. Bring some smart people together—usually developers and designers as well as product management and marketing. Consider the end goal and work backward. What problems do you need to solve? What personas are affected? What technology is needed? And what key events occur along the way? Those events could be great opportunities to get market feedback on your work-in-progress or release some basic functionality. Sequence the big chunks of work. Now you have a roadmap. Just remember, a roadmap is never a release plan.
Problem story. Describe a persona and a problem scenario. Don’t tell the team what feature you want. (You’re probably wrong anyway). Product managers are problem-finders. Engineers, designers, and developers are problem-solvers. Sure, the product manager should participate in design discussions—primarily to represent the customer and your business. Product managers look at design from the standpoint of “Does this solve the problem?” and “Is the solution viable for our business?”
To succeed, products must solve problems that are vital to the buyer (or else they won’t buy it), valuable to the user (or else they won't use it), and viable for your business (or you can’t continue to offer it).
Asset Brief. Create a one-page definition of a problem that will be solved with a marketing asset.
Suppose your win-loss analysis reveals that buyers are confused about some technical decision that is core to the product. When this occurs, the sales team taps the product manager or a developer to connect with their prospect to explain the details. If this occurs routinely, then you need a better solution.
When product marketing managers discover an aspect of friction for buyers, they sit down with a marketing specialist to solicit ideas on how the problem should be solved. In this case, the marketing specialist offers a couple of suggestions: a printed technical brief and a video of the technical architect describing why the decisions were made. The technical brief can be done rather quickly, but the video will be more effective. They decide to do both—the brief addresses the immediate need, and the video will be more effective and can be done when resources allow.

Product is a team sport
A relay race is a competition where members of a team take turns completing parts of the course. And it’s rather amazing how challenging it can be to pass a baton from one runner to another. The second runner must accelerate to match the first runner’s speed. The first runner must make sure the baton is firmly grasped by the second runner before letting go. Most runners also call out instructions such as "STICK!" repeated several times. And they must do it while both are running in a marked exchange zone. Drop the baton and you’ve lost the race.
That’s how teams work. They each have competence in their own areas but collaborate when their work intersects.
“STICK!”
The best results come from teams that collaborate and communicate. Write your documents together to ensure everyone understands what’s needed.
תגובות