Cultivating Taste - Product Management I, What Drew Me Here?
Exploring how better Product Management may have saved my work projects and why that has me interested in the field
It’s Tentacle Time
In Post 1, I shared a few different mental “tentacles.” Then, in Post 2, I shared more background on myself and why I’m here. In this post, I’m going to get into my first tentacle - Product Management.
What Drew Me Here?
My interest in Product Management was sparked by a couple of flopped projects at work. The projects were internal machine learning (ML) solutions. After months to a year of building, when it came time to deliver to the customer, the solutions didn’t fit. This was frustrating. The pain of all the wasted effort left me exhausted and all I could think was “how did this happen?”
What Went Wrong?
After plenty of thinking and a bit of reading, I ended up coming back to a lot of ideas I learned in a “Lean Startup” class in college.
I recognized two missing pieces in our project process:
The lack of an extensive problem identification, definition, and validation process.
Failure to deliver and iterate on the final product/interface soon enough
Problem Identification and Understanding
Like I mentioned earlier, the projects were internal. That means we built them for other teams in the same company. That should make things easier, right?
The first mistake we made was a shallow problem understanding phase. The other team came with a loose problem statement and we ran with it, diving into their data looking for “interesting” events.
To be fair, the initial phase is always exploratory. It’s called Exploratory Data Analysis (EDA) for a reason. But this name can be a crutch when you get to it before doing enough due diligence up front. A solid business problem adds constraints to the exploration. Without those constraints, “interesting” findings can catch the eye of your whole team and lead you down a different path than was originally intended.
Iterating on the Final Interface From the Start
Next, we let the end product stay too abstract for too long. We met with the team on a weekly/bi-weekly basis to present our analysis to the customer. The events we showed were interesting, but they were presented as dashboards, not what would actually be shown at game time. This made it much harder for them to critique the the findings. When they were uncertain, they could think things like “that does look interesting. It must be useful…” which made it harder for them to give the critical feedback.
This could have been solved by creating mock ups of the intended solutions. Instead of showing dashboards, we should have shown the data/image/alert they would receive, at what time, how they could interpret it, and then listen to what they said. The feedback we received would have been much more actionable. Instead the intermediate representation we showed them left room for the team to assume we’d be able to make those findings useful later on.
Part of the reason this got left out is because it’s harder than everyone expects - and it is work that doesn’t fit a role on many teams. There was no UI/UX/product person on our team whose job was to focus on this. The engineers focused on the data and technology, the customer focused on their job, and of course managers aren’t expected to build things. So, when it came time to think about the product, it was easy to brush it off as a tomorrow problem.
Comprehensive Understanding
My hunch for how this happened is that there wasn’t a go-to person for each of these projects with a deep understanding of all aspects. Each person could speak to at most 2 of the aspects of the projects:
business needs
subject matter knowledge
software
ML
end product
In the case of the end product, no one could speak to it well.
This left a lot of cracks for miscommunication.
Product Management to the Rescue?
As I thought more about those problems, the solution started to sound like Product Management. The thing is, I’m not quite sure what Product Management really is. So that’s what I’m exploring in this post. What is product management and how may it have helped prevent these failures.
What Is Product Management
The best description I’ve found is from Daniel Schmidt’s blog Product Logic.
His view is that Product Managers fill white space.
Product Managers Fill White Space
In my last post, I shared how my experience in school fostered a discomfort with ambiguity.
“Filling white space” might be the most ambiguous job description of them all. Realizing that this ambiguous role is what was missing from my team is part of my recent interest in areas requiring more ambiguous skills (ambiguous still doesn’t feel like the perfect word here, but it’s the best I’ve got for now).
Okay, it’s important. But, what does “filling white space” mean?. What white space needs to be filled? That is where Daniel’s Product Management Triangle comes in. It is his method for illustrating the white space that great PM’s fill.
The Product Management Triangle
I won’t do his entire post justice, but I’ll hit the highlights.
Here is the skeleton of the Product Management Triangle for software products.
The triangle is centered around the product, which for a software company is some code deployed to some environment that users interact with.
Developers are the ones who push code. Dan has a funny quote about developers: “the people updating the code are the only folks on the team who are strictly necessary. Developers can perform all company duties (while not always effectively)” (emphasis mine). This is funny because it is true in principal, but I doubt it ever works. It’s also funny because it is a driver of engineers’ egos. I know it was part of mine. We are the ones actually building shit. Why are all these other people even around?
Then, we have the users. The ones who actually use the product.
Lastly, we have the business. The business “is the entity that funds and hopes to benefit (e.g. profit) from the product.”
Here is the same triangle with the white space filled in with example roles:
Regions A, B, and C are white space within the company.
Regions AB, AC, and BC are “synthesis regions.”
A product manager has two broad responsibilities:
Product management must recognize and fill the important white space between the elements of the product network; i.e., manage regions A, B, C. If an essential link is missing, the product manager must act as that link or find a way to fill it. Towards this end, a product manager must be able to at least adequately fill all roles surrounding a product, from web analytics, to account management, to project management.
Product management must synthesize the different inputs affecting each element in the product network; i.e., manage regions AB, BC, and AC. A product manager must own the company’s narrative for each element. Developers need a clear story for what to do. Users need a clear story for how to use the product. The business needs a clear story for the product’s contribution to the world. Through an act of synthesis, the product manager is the author and evangelist of these stories.
PM’s are fillers of white space and synthesizers between white spaces.
Environment Builders
A successful PM fills in gaps so that other people in the company, like the engineers, can work within constraints that allow them to be as effective as possible.
They fill gaps so other people at the company don’t have to. They synthesize information from disparate parts of the company to create a clear narrative and goals so different departments know the most effective thing to focus on.
How would Product Management have solved our problems
We worked with an internal team, so the triangle is even simpler. Most of our focus was in white space A.
Funnily enough, our problem was a lack of focus on the center of the triangle - the product itself. We got obsessed with the technology and felt good when the customer told us our graphs looked cool.
A stronger focus on product would have consistently brought us back to the center of the triangle. What is the end product? Translate all that cool technology into something actionable, a UI, an alert, something concrete.
The End Of Part 1
Writing this was frustrating. My experience felt so complex. There were a lot of moving pieces and a lot of hard work. But at the end of the day, the fix seems so simple: focus on the product. How could we have missed that?
It’s so simple, it seems like we could have fixed our problem with a simple reminder:
Constantly ask “why?” to remind you and your team of the reason you’re building. That’s my step 1 for avoiding this same trap in the future.
In the next post, I’m going to get into more of my personal taste on the subject. Do I think I’d like to be a product manager? What skills and experience do I have that support my opinions? We’ll see where it goes from there.
Writing this was also frustrating because it’s not my best. I struggled on a lot of parts and know they could be better, but want to publish in the spirit of getting more work out there. That said, I would great appreciate any feedback! Anything from particular writing advice, to things I got wrong about product management, to something that may have resonated with you.
See you in part 2!