There’s a lot of great advice out there for folks looking to move into product management roles. In fact, we contribute a lot to this very conversation in a regular segment of the 100 PM podcast called “get the job, learn the job, love the job.”
So today I want to focus on what to do after you’ve broken into Product Management.
Observe the ship first
Great military captains make a practice of observing the ship for 30 days before taking over command. Are they lazy or just afraid?
Neither, actually.
Whenever we enter a new situation our instinct is to show up big. But there’s a tremendous difference between taking action and making an impact. In the the former, the metric is movement.
Move this task from unstarted to started. See? Progress!
Move this uncooperative person off the team. Look at me manage!
Whether our current role gives us the jurisdiction to reallocate resources or simply to reprioritize the backlog, our tendency when we first become PMs or start a new job is to prove effective at getting shit done quickly.
How ironic that this approach causes us to betray our number one product manager superpower: problem finding!
If we learned anything studying the art of customer research and conducting effective interviews, we learned that most of the time people are not connected with their own pain.
Organizations are not exempt from this phenomenon.
Maybe some executives believe certain problems exist because of certain people. Meanwhile the folks in the trenches are often taking aim at “disconnected” management and antiquated tools for “the way it is.”
Symptoms of dysfunction rarely point clearly to any one cause.
So whether we’ve been hired specifically to get things in order, or whether we’ve just taken on the mandate because we’re wired that way, it’s good practice to start by simply observing things as they are for a time before making changes.
This practice will guide us to the leading indicators of organizational pain or product problems, which we can now begin to influence with confidence, rather than assumption or bravado.
It’s the “ask questions first, shoot later” achievement.
My friend Cody Rice at GoGuardian describes this challenge as navigating the implicit expectations of the job, rather than the explicit ones:
“A product manager's implicit expectation is that they're going to do the most impactful things to benefit the company through their product. That expectation is not communicated on paper and it's not going to be a KPI. It's not going to be, ‘Increase the revenue from one million dollars to two million dollars over the next 18 months through these efforts.’ It's zooming out and saying, ‘With my skill set, with my expectation, with my knowledge, where should I be spending my time in the most impactful way?"
When we observe the ship first and then target problem areas, we make more than just waves, we create value.
Go on, get RACI
In a perfect world we’d start every new job with a copy of the org chart on our desk (as well as a new Mac laptop!).
But product manager life isn’t perfect and most companies do a terrible job of communicating organizational structure transparently.
That means we may be left clueless about who our key stakeholders are.
Moreover, given that product teams are typically cross-functional, many of our direct collaborators may be shared across departments, committed to deadlines and deliverables that we have no idea about.
So don’t wait around helplessly. Leverage your keen powers of observation and build a stakeholder register of your own to start keeping track of who’s who and how they can help (or hinder) your activities.
A common style of stakeholder register is called a RACI chart, which stands for Responsible, Accountable, Consulted and Informed. Just one of product management’s many acronyms!
You can use RACI charts on a project by project basis, or more globally in lieu of an org chart if necessary.
A RACI chart is laid out like a table, with tasks or job functions in the leftmost column and each team member (or department) in the columns to the right.
Then for each task row, you can ascribe an R, A, C, or I value to each individual depending on their level of involvement.
For example, R = the person who is responsible for getting the task done and A = the person whose job is on the line if the execution fails.
I’m kidding.
Hopefully accountability in your organization is not equal to getting fired if things go wrong.
But if it is, wouldn’t you prefer to be informed?
Establish process
I recently received an email from a new PM I had previously coached, asking what software I would recommend he use for managing software delivery.
He expressed challenges with the customizable nature of JIRA, and was evaluating Asana as a suitable alternative.
Actually I think Asana is a great project management tool and its new card feature is a valiant effort to defend against Trello’s offering.
But that’s not the point.
When it comes to tools, any software you select is only as good as the established process that informs how you will configure and use the tool within your organization.
The catalyst for this tool search was a product release that didn’t go smoothly (welcome to product management!).
The instinct, of course, is to slap a tool on top of organizational pain. Certainly it’s a reportable improvement:
“We installed JIRA so you can rest assured we won’t have any more production hiccups!” - meant nobody ever.
In this circumstance we can (again) learn a lot from the concierge approach to product development, a path taken by the folks at Groupon and Food on the Table and well documented in Eric Ries’ book The Lean Startup.
The fundamental tenet of the concierge MVP (minimum viable product) is: manually service the workflow your product seeks to automate. It’s not a scalable practice but pays heavily in lessons learned about how things should work.
Applied to organizations, and building on the lessons shared above, the advice here is:
-
Seek first to understand what is the current process for doing something, if any?
-
If problems have emerged, why have they emerged? What exactly caused this launch not to go smoothly?
-
Improving software delivery process is a fundamental part of any product team’s agenda and there is much to be learned and tried in the world of Agile practices like Scrum, Kanban and Extreme Programming (I highly recommend acquainting yourself with Mike Cohn’s training over at Mountain Goat Software if you go the Scrum route)
-
Once you understand what good process could look like, take an Agile approach and seek to incrementally improve by adopting small changes to your current process and then measuring the results (because build-measure-learn)
Remember: good software helps to improve process, not to define it.
And while we’re on the subject, here’s a few more processes beyond software delivery that you may want to help establish:
Features prioritization.
The good folks at ProductPlan have written extensively about different methods for prioritizing features in their awesome free-book.
Or perhaps you’ll be drawn to the Kano Model, which I’ve written about here on our site.
Whichever method you choose, pick one! Arbitrary decision-making as to which features make the cut and which get deferred is a guaranteed exercise in stakeholder disintegration.
Storytime.
“Storytime” is an informal Scrum process sometimes referred to as the “Product Backlog Refinement meeting;” an opportunity for product managers and key team members to come together, better define user stories and acceptance criteria and initially estimate level of effort.
Storytime is a great example of establishing process to address an organizational problem: in this case the problem of inadequately prepared stories in the product backlog creating a bottleneck in production (to wit, our problem as product managers / owners).
Customer Feedback Collection.
By now you know just how important it is to talk to your customers early and often for important clues about which direction to steer your product in.
But customer research conducted without a plan typically leads to key insights put into word documents that get filed away and forgotten.
If you’re going to make the effort to hear from your customers - and you absolutely should - then take some extra effort upfront and establish a process for how you will collect the feedback, analyze the feedback, and share the feedback so it can be integrated during, um, storytime.
OK. If you’re looking for more rants on the merits of process, check out this earlier post called “Trust us, you need process."
Otherwise, I’m moving on.
Conduct a gap analysis on your own skillset
A lot of students ask me which skills they should start boosting even before they’ve graduated my Introduction to Product Management Course.
It’s natural to want to gather up as much knowledge as you can before you get the job, but the reality is much of being a great PM comes from learning on the job.
As a generalist function, the required product management skillset is a mile wide. The good news is that the minimum entry is usually just an inch deep.
What does that mean?
You were conversant enough on product management topics to get the job (and you can stay conversant by checking in here from time to time), let your surroundings best inform exactly what you need to know next.
Are you struggling to understand what your collaborators are talking about during sprint planning session?
Are you feeling shy about sketching out some workflow diagrams next to your rockstar UX person?
Did somebody just use another acronym that you can’t decipher? Of course they did, it’s product management!
Now that you’re working alongside great folks (and maybe some not so great ones too) you have direct information about where you’re lagging in the skills and knowledge department. Start here!
Alternatively, try listing out all the skills and qualities desired in a senior product person (company job descriptions provide great cues for this) or take the 12-point PM quiz to see where you currently stack up.
The results are your roadmap to becoming a great PM!
One final word of caution: you can go deep with product management to be sure, but the best PMs accept that their destiny is not to be an expert at anything (except maybe the customer’s needs) and are comfortable leveraging the expertise of their team.
Which leads us to...
Don’t fall in love with your own solution or: How stay connected with your customer
Now that you’ve found a home in a product company, you’re sure to drink some Kool-Aid. And why wouldn’t you?
But too much Kool-Aid, too many rockstars, and too little getting out of the building is a recipe for building a vacuum that seals you and your team away from the reality of what’s happening in your market.
So.
Let your user goals, not your designer or developer, settle the debate about how the feature should look and work.
Take a page from Jeff Bezos and wheel that empty boardroom chair into important meetings to hold space for the customer’s POV.
Or take it up a notch like the awesome folks at Sonos and build a killer living room to simulate your customer’s situation at the point of product need.
Stay connected.
Stay curious.
Embrace a mindset of “maybe I know,” over a mindset of “I know.”
You’re going to do just fine.