I recently spent time with some new product managers and nearly all of them commented on how they found it difficult juggling the different disciplines involved. They’re right, there is a lot to juggle, and the context switching can cause some serious whiplash and brain-drain. Each phase of product development requires a different perspective, almost a different mindset. At one end of the scale you have a big-picture view of the world, like looking at the market you’re in and hypothesising new value propositions. At the other end you have nitty-gritty details like the pixels and font-sizes of your UI.
I wanted to try and document these differing perspectives and come up with some advice on how to manage the constant switching. Here’s a diagram to illustrate this spectrum and how the different activities of product development fall into them. (I should mention that this isn’t a comprehensive description of how to build stuff).
At the top end you’ll find yourself with a big-picture view of the world, and at the bottom you’ll be sweating the small nitty-gritty details. I’ll quickly rattle through what each of these entail, with some context from my team (at M&S Digital Labs):
Big-picture: Value proposition
Starting with a broad view of the world, here you’ll be thinking about the market you’re in, your business model and your value proposition – what it is you’re going to offer your customers.
Nitty-gritty: Customer development
From there, customer development will take you into research mode to unearth insights on customer drivers, behaviours, and pain points. We’ll conduct guerilla research in the street, as well as in our stores, to learn as much as we can about our customers.
Big-picture: Product principles
Having gathered some insight it’s back to the big picture. Time to think about how a solution to the problem you’re going after might look. Broad principles that span most products will be UX things like effortlessness. In our team we also borrow from the marketing and branding worlds, thinking about things like the tone of communication we’d like to use.
Our designer Pete ponders his product principle post-it.
Nitty-gritty: User flows
We go back to the nitty-gritty with user flows, defining the journey we want our customers to take. In our team this artefact is simply boxes and arrows on scrap paper. We’ll refine the flow as we identify points of friction. We’ll also map where data goes in and out, and think about any other moving parts involved in the experience.
Big-picture: Wireframes
Happy with our user flow, we head back to a high-level point of view to think about the user interface and interactions. With more boxes on scrap paper, we try to keep things light-weight in favour of iterating in the browser as we bring it to life.
George struggles to decipher Neil’s wireframe, which he’s clearly quite proud of.
Nitty-gritty: Code + pixels
Perspective changes again as we start to write code, with the team cracking on with the backend. For the front-end we stick to our mantra of “do it in the browser”. Here we’ll sweat the smaller details of visual design, nudging margins and font-sizes as we go.
We’ll continue building and shipping (our current record for deploys to production in a day is currently 31) until we’re ready to traffic and measure.
Big-picture: Core metrics
Back up to a high-level view to think about your metrics. With customers using the product you can take a couple of steps back and look at what they’re up to. If you’re not sure what you should be measuring, take a look at Dave Mclure’s Metrics for Pirates (AARRR!).
Nitty-gritty: Data
Back to the nitty-gritty detail of gathering data. Here we’ll be knee-deep in analytics, spreadsheets, and pivot-tables. In our team we’ll make life slightly easier for ourselves with hand-rolled dashboards for key metrics.
Avoiding whiplash
Hopefully this whirl-wind flow (with its generalisations) illustrates my point about the constant shifts in perspective. Be warned, these can cause dizziness, brain-melt, and/or whiplash.
I’ve found having an appreciation of these shifts in focus can help anticipate them, which in turn helps to reduce the pain when jumping around.
For people who are new to a product team, having the discipline not to jump around too much in the first place is really important. It’s hard to avoid when you’re in fire-fight mode, but it’s important to only do one thing at a time, and to flow amongst the big-picture and the nitty-gritty detail as you move along.
This illustration can also prove as a good sanity check. Every few days take a step back and assess where you are. Ask yourself if you’re working on the right thing, and if your level of focus is right. Is it too much or not enough?
Thoughts?
I’d love to hear about your experience and hacks to avoid whiplash when you’re in the thick of it. Ping me @hemalkuntawala.
This is a far better article: https://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/
What make’s it difficult for Product Managers is getting to the
understanding that Product Management is not Product Design. The first
two points are valid in this article. Value proposition and Customer
development and so are the last two Core metrics and Data. The other
three are an entirely different discipline. User flows, Wireframes and
pushing pixels.
While the Product manager is across the entire product, they must be
able to work with the experts (Creative Directors and Technical Leads)
to get the product out on time and on budget. It’s with collaboration
and respect that Product Managers can avoid whiplash, which is probably
gained by being slapped around the head by a designer/developer.
Everyone can paint. But not everyone is Michelangelo.