This post was originally published on Medium on Jan 17, 2018.
At Pivotal I am proud to be surrounded by a diverse set of peers working as Product Managers. That is to say it is just as likely for PM’s to have a background in UX or design as it is Engineering and both foundations are effective building blocks to leveling up within the Product Practice @ Pivotal.
This means product managers need to be as comfortable at the command line as they are with sticky notes and 2×2’s. I believe this to be true of all Product Managers, even at engineering driven cultures — this balanced approach is at the heart of what I have to come to think of as Product Thinking.
Build what matters
These ideas around Product Thinking are rooted squarely in the fundamentals of Design Thinking. As I outlined in my previous post about writing good user stories much of the day to day responsibilities for PM’s revolve around understanding user problems, gaining consensus around solutions, and breaking those solutions down into small experiments with measurable results. Build, measure, learn. This is often a collaborative process between Product Managers and UX Designers and as products grow you often see multiple teams grow out of specific user needs. This work is often overwhelming, and time consuming for Product Managers to take on alone; having a UX peer to synthesize and provide outside perspective is incredibly valuable (and available) to PM’s at Pivotal.
That said, when the service blueprints and style guides turn into code and acceptance criteria they start to be referred to as “artifacts”. The realm of preservationists and future UX researchers — still this is the critical arc for the story of your product and how you recruit missionaries not mercenaries.
Building the right thing is far and away the most important factor in building successful product teams — that’s why outside design help is so necessary for Product Managers.
This is evident in how many organizations are defining the role and in fact many companies encourage blurred lines between disciplines of Design and Product. While I applaud this colloboration I also think that the what sets Product Managers apart from designers is a clearly defined contiuity to delivery. Which brings me to my next point.
Ship it!
While the upfront planning, collaboration and writing of user stories is a critical function of a Product Manager it’s only the first half of Product Thinking as I see it. So much importance is put on techniques for prioritization and planning that many new PM’s are lacking in this skillset.
A product manager should be as comfortable at the command line as they are with sticky notes and 2×2’s.
When I am coaching product managers, the excitement and training materials are squarely focused on the first half of Product Thinking — build what matters, but shipping and testing are equally important. If you have a feature that you don’t know how to test you shouldn’t even prioritize it for your team. This risks building up inventory. Not knowing how to test (or measure) outcomes complicates priorities for Product Managers tremendously. That said with time, and user evidence a team will eventually break down problems enough that you will have testable features emerge.
Notice I said team — I am referring hear to big Problems that need involvement from everyone to translate into smaller features. If the team has sufficiently broken down the problem, and the evidence still supports the solution may solve the problem there should eventually be a plan that not only ships your new feature, but can measure it’s success (and lifetime value).
Product Thinking considers the lifecycle of every feature from testing to deprecation.
To be proficient at this half of the job it is helpful to have an engineering background but that’s not actually necessary. The only pre-requisite to being successful at delivering software to users is curiosity about software and time spent satiating it. If you are naturally curious and organized you can be successful shipping software with enough practice and learning.
It’s also about the relationship with engineer on your team. Much the same way drummers are people who hang out with musicians, PM’s are people who hang out with engineers. Without one you can make some interesting things, but rarely a hit. Having a productive creative relationship with engineers means valuing and understanding their contribution. The best way to do that is to make sure the software they are building has an impact (see first half ;-).
It’s worth pointing out that many organizations have grown their product practices out of engineering and therefore need the focus on design thinking is a necessary pendulum swing back to the middle for a practice where balance is essential. If you transitioned into Product Management from an engineering or development background don’t continue to lean on those skills. In fact you probably should focus on the next aspect.
Telling people about it
The reality is, even if you built the right features and shipped them quickly to production if you don’t spend time telling your users about them your product will not evolve. I like to joke that this is the third half of Product Thinking. That joke is based on some real best practices too — many organizations set aside equal budget for marketing as R&D. I worked in advertising and found the reality of this to be a bit nauseating but this practice emerged as an important problem of market design and is something PM’s need to understand.
It also varies widely from one organization to the next. Marketing, Product Marketing, Business Intelligence, and Partnership teams are involved in the practice of end user communication but PM’s also need to communicate with leadership and other engineering teams to successfully solve user problems. This is as important to understand your organizational structure as it is your product (spoiler alert, they mirror each other).
This is also largely an area that I am not an expert in. That said, metrics are the common language of all these teams. Each team likely has internal and external metrics that serve difference purposes, but ideally your product also has a star (⭐)metric. One metric that all teams can center around for design & engineering decisions which ideally is the differentiating metric for your marketing team.
Bringing it all together
Being an effective PM means balancing these skills and understanding your strengths and weaknesses. Most people gravitate towards what they do best naturally, but stepping out of your comfort zone and focusing on improving the areas you struggle most will benefit your growth more considerably. It also means seeking out what could be unlikely mentors — some of the best mentors for PM’s are individual contributors that can take the time to teach you what it is like to be an Engineer, Designer, and/or Marketer for your product. Taking the time to empathize with all of these teams is what I have seen the best PM’s do.
