As my summer vacation activity I decided to personally sign up for Melissa Perri’s Product Institute program. It is a teense pricey, but reasonable if it is a good product. :+).
My fav moment so far was when I took the first quiz and got one question wrong, and it made me really happy.
So I say, “Phew!” Let’s definitely push Product Managers over to the uncertainty in the entire process, and let the opinion about “good design” live more often with the designers.
Sign up for the Resilience Tech Briefing with no more than 2021 characters, zero images, and all in plain-text.
Creation vs Improvement vs Maintenance is how Perri frames the product lifecycle, with each mode requiring a related but different plan of attack.
“The problem with Gantt Charts in software is that our work is not as certain as manufacturing processes. We are knowledge workers, and we need a planning system that accounts for that.”—Melissa Perri on why roadmaps are different with software products due to their tighter user (and more fickle) associations that mandates more integrated research for build.test.learn that is different than building a mechanical system like a bridge, car, or house
It is easier to ask, “Can we build this product/feature?” versus “Will this be a successful product/feature?” The former is a maker-centric task that is unequivocally difficult yet still highly deterministic. The latter, non-deterministic outcome needs to be lucky to have addressed requirements of producing desirable value to the customer and business value to the company to make back their investment to get the product/feature made.
“… it’s not the user’s job to solve their own problems. So let’s stop asking for requirements and instead start looking at their needs.”Melissa Perri
On backlog grooming: 1/ what problems are being addressed? 2/ are there just solutions masquerading as problems? 3/ is only unmet need being addressed or are is there a little unrealized need in your backlog?
“It’s important to balance good design with fast design and good development with fast development. The best way to do this is getting designers and developers to pair together.”Melissa Perri
Perri isolates many of the common issues when working across roles, like when doing ideation sessions like six up a la design thinking:
“I’ve found that if you called them “Design” studios, developers are more afraid to participate.”—Melissa Perri
I like how she advocates for empathizing with stakeholders as a key aspect of change management by asking questions:
- How are stakeholders measured for success in your organization? What are their goals?
- Who is influencing their decisions? Their team, managers, board?
- What is their background? Do they know your way of working or what you do?
- How are they feeling about this project? Left out, included, in control?
And this take on how working with classical design people from the agency world requires a special kind of empathy is so spot on:
They simply believed that their design process was the best way to create good products. That is how they had been taught and what they had been doing forever. They also worked at large companies that produced mostly print products. In these industries, once you shipped there was no going back and iterating. They didn’t understand another way of working.—Melissa Perri on agency creative bosses as stakeholders
Perri’s list of how to rationally manage stakeholders is a gold standard:
- Do not ask for requirements. Ask for any dependencies and new information on the Stakeholder’s side that might affect your work. Tell them this is informing your solutions.
- When asking for feedback, make it direct. Instead of asking Stakeholders, “What do you think?” ask them to test your product and answer tough questions that rely on their expertise.
- Rely on data to justify your decision making. If someone does not like the design, show them that your customers are responding positively to it with user research sessions.
- When presenting Roadmaps and Prioritization to Stakeholders, be transparent about your process. If a Stakeholder insists that work for their team be prioritized over something that another Stakeholder is invested in, make them talk it out between themselves and make the decisions.
Much of UX and Product overlap and share roles. Product Management with no User Experience Design creates functional products that don’t make users excited. User Experience Design with no Product Management produces delightful products that don’t become businesses.—Melissa Perri on PM and UX collab
“Product Managers own the WHY. Designers own the WHAT. Developers own the HOW. The team owns the WHEN.”—Melissa Perri
Consistent takeaway across entire PM ecosystem akin to Sullivan’s vacuous “Form follows function,” is “Outputs to outcomes” — which translates really as, “Getting lots of things done versus the right thing done.”
- Useful free JTBD product-centric book from Intercom
- On the only requirement being the user problem definition
- The difference between unmet vs unrealized needs
- Qualitative cost of delay as rehashed Eisenhower matrix
- Wonky weighted shortest job first heuristic is pseudo science
- Love Aurelius tool for consolidating research insights and Leankit is kewl.