Open Product Management
This post is the latest in a series of explorations by Alan Berkson and me into what we are calling The Control Scale, a guide to digital communication and collaboration. If you’d like to stay up-to-date with our happenings, please subscribe to our mailing list. Yeah, it’s old school, but email is not dead. Mistreated, maybe. But not dead.
As a Product Manager, I rely heavily on my user base to supply ideas and suggestions to improve my product. Ensuring the entire process is open allows for well-vetted feature and enhancements requests. Below is the basic flow. I’ll explain the benefits of keeping each of these steps open to the user base.
User posts feedback → Community validates (comments, likes/upvotes) → Categorize → Prioritize in road map→ Create development story → A/B Testing → Share results → Finalize story →Prioritize for development → Test → Feature verify → Move to production → Announce release notes → Share analytics → Ask for further feedback → Users post feedback
It seems like a lot of steps, but they move fast and users feel ownership since open, evidence-based decision making is happening the entire process. Let’s look at each step:
User posts feedback — this feedback could happen anywhere (Twitter, in-person), but ideally it would end up in a dedicated forum with a user community. Users need to know their voice is heard and that they are the ultimate influencers of the product.
Community validates — if the feedback is bad, fellow users will let them know and often explain why. If the community consistently likes, upvotes or reinforces suggestion in comments, you’ve got something to consider.
Categorize — what part of the product does this fall under? Depending on your product, you may have several product managers with their own portion of the product. Who should it be fielded to?
Prioritize — I use this quadrant (apologies, I don’t the source of this image) to decide to assign a priority. 1s and 2s move on to the next step. ?s get added to the backlog for future consideration. The 4th box gets filed under feedback. Where does this fit in the overall road map?
Create story — This is where we work with the user experience and user interface teams to display exactly how the enhancement would work. This could take a couple of iterations with feedback from the community. It needs to be precise and specific as the developer team will need be executing the story details.
A/B testing — My favorite step. If possible, we make user interface alterations to a small percentage of the user population and measure their experience. Try a variety of experiments. Can you scientifically measure the improvement of the enhancement? If so, let’s move forward.
Share the A/B testing results — regardless of results, the data should be shared with the community to explain why you are moving forward or not.
Finalize the story — with further feedback from community and A/B test results, we can finalize the story to hand off to the dev team.
Prioritize for development — whatever this enhancement is, I’m sure it will be competing with other feature requests, technical upgrades and any other work the dev team is already pursuing. The end user may assume it’s just a flick of the switch, but this prioritization needs to be made and communicated by the product and dev teams: the amount of time it takes to make the complete the feature, when it will actually be worked on, and where it stands in the priority list.
Test — test test test. Communicate what is going wrong and why it may delay the rollout.
Feature verify — Once all tests are passed, the product team makes the decision to move to production environment.
Move to production — Set a date, share expected date. Note that communicating feature verifications and expected production move dates keeps the pressure on all teams to deliver in the expected timeframe
Announce release notes — Make the announcement of what has been changed. Call out individuals who helped make it happen.
Share analytics — Based on the A/B testing, you should have identified experiments which show the value of the product feature or enhancement.
Ask for feedback — ask for feedback to further refine based on analytics and release notes.
User posts feedback — the circle of open trust, round and around we go.
