33. www.productschool.com
Part-time Product Management, Coding, Data, Digital
Marketing and Blockchain courses in San Francisco, Silicon
Valley, New York, Santa Monica, Los Angeles, Austin, Boston,
Boulder, Chicago, Denver, Orange County, Seattle, Bellevue,
Toronto, London and Online
Hinweis der Redaktion
Intro
Share recent experience with a new building process: building with empathy
First, let’s start with the MVP
Often see diagrams like this with proper way to build
Explain slide for those who haven’t seen it
This is one good at determining functional build
Different opinion on what’s required in MVP
In additional to function, must be delightful AND usable to provide customer value
At Dollar Shave Club, such a large part of our offering is tied to emotion and usability that it behooves us to build with these as necessary drivers of customer value on top of core functionality.
We must be able to empathize with our customers in order build successful products.
While good at the what, these diagrams don’t explain the how
What does it mean to build with empathy?
Let’s start with the basics: what is empathy?
The ability to understand and share the feelings of another
Must be empathetic to customer’s needs to provide product/feature that delivers value
Argue that it goes further than the customer, but business and team as well
Non-empathetic way
How many times have you heard:
“Why are we even doing this?”
“Deadlines are purely arbitrary”
“Make your engineers work faster”
Empathetic way
As a product manager, it is our job to act as a catalyst to inspire our teams, not to tell them what to do
It is in building a product with empathy for the business, for the team, and for the customer that will lead success.
So how can this be accomplished? Would like to share experience with a recent project.
Wanted to try different approach: project charter
Asked questions as a team:
“Why are we doing this”
“What does success look like”
“What KPIs are driving this project”
“What is the state of the current landscape”
“What are the risks/dependencies”
Stuck points on the wall
Group members
Some valuable takeaways:
Engineers expressed concern with legacy code base
Stakeholder could communicate why project and deadline were necessary
Set and understand goals together as a team instead of trickling down from the top
Crucial step in building empathy between parties
Brainstorm on potential features
Competitive market analysis
Online user interviews
Value / effort session
Rapidly plotted ideas to get a gut check of value / effort from the team
Longer discussion with trickier ideas
Empathy was becoming more apparent
Teams were engaging in meaningful conversation around user/business value and were mostly aligned
Took the points from the value/effort session and began designing
Three rounds of prototyping
Playback sessions with the whole team + stakeholders
Revising until a final plan was set
Knowing what features were valuable to customers and effort estimates drove MVP
MVP would deliver emotional value while being usable and provide the right functionality to be successful
Fast forward, run into the inevitable: descoping
Unfortunately not due to a lack of planning but resources and business priorities
Historically, descoping was a matter of stripping away whatever couldn’t be built
Silver lining
This time conversations happened earlier
Descoping was more mindful of keeping necessary features and functionality
As of today, still working. It hasn’t been perfect but it’s been an improvement
Excited to see how this feature will behave in the wild
In my experience with this process I have seen that...
Ultimately, we have yet to measure success
I am confident
Confident that planning and design was right process
Confident we succeeded in fostering empathy in team and stakeholders os shipped product is better and more thoughtful
Team demonstrated more drive and positivity
I hope that in sharing my experience there are pieces that can be useful in your day to day or when building that next big project.