The details matter. Getting them right can be the difference between conveying a subconscious sense of credibility - or not. Pay attention to pixels, colors, margins, voice and all the things that "don't matter"
Filtering by Category: Product Management
"You're always very engaged in meetings"
A startup exec I've been working with said this to me recently.
She then went on to ask "Is it because, as an external advisor, you feel like you have very short windows to add/prove value?"
The truth is I've always felt the need to be super leaned in to meetings. I've never felt like I could coast/relax at any stage in my career.
When I was very young (15-22) I was the youngest person in the room - trying to convince 50+ year olds to do this "technology thing" my way.
When I was slightly older (20-30) running my own startups, I felt like every day and every decision was life or death. I was deeply invested and felt the weight of the world on my shoulders to come through for my team and my investors.
When I was at Uber, I was surrounded by some of the smartest and most experienced people in the world at their job. Combined with the fact that I felt like I had a real opportunity to make a difference at scale, meant that I had no choice but to be wide awake!
And now with my Advisory work, as she suggested, I feel like I have very small windows to really contribute/come through for the founder and the startup.
It's interesting because I'm also increasingly realizing I've been at a disadvantage my whole career due to my lack of caffeine intake!
In any case, I had always assumed everyone felt fully engaged for pretty much every meeting.
Now that I've made you angry. Here's what I actually mean.
Even the best product thinking engineer should not be placed in the position to be both a product manager AND an engineer on the same product/project.
Product management is often about saying NO. It's about long term, big picture thinking. It's about the what, when and IF something should be done. It's about stakeholder discussions, consensus building, visual design, marketing, customers, business considerations and more. It's about picking which hill to take, bringing the right team together and motivating them to get it done (to use a military metaphor).
Engineering, on the other hand, is mostly about saying YES. It's about getting the job done. Solving problems. Figuring out HOW something WILL be done. It's about being deep in the details of the code and trying to find your 'zone' to make magic (a zone that is easily interrupted by meetings!). It's about being the person the product manager can depend on to actually run up the hill and plant the flag while they're off picking the next battle field (to continue the military metaphor).
These are totally different head-spaces and roles. Often they work well together. Sometimes there's a healthy tension with one side pushing the other to "do more" or "get more focused" or "be more specific" etc (in both directions).
Someone with an engineering background might actually be an excellent product manager when placed in that role (and they often are!) but asking ANYONE to do both roles is often asking too much.
You need a strong Product Marketing, BizDev and Sales org to drive demand. You need to have them coordinate and be lead (via influence) by Product (not the other way around).
Often times product strategy is a combination of experience (knowing how apps typically solve a UI/UX problem - i.e industry best practices), good taste (having good judgment about what looks good and what doesn't), and empathy (having strong intuition about how and why given users might behave or react to certain things). Data and research can then be used to interrogate these instincts.
Almost the moment you decide on a more specific user persona, additional, in-depth product insights and priorities emerge that help you truly specialize your offering for that market.
That's also the difference between Tech.
Tech can "do anything".
Product does very specific things for very specific users in very specific ways.
I've noticed a lot of product managers end up in a situation where an avalanche of shit is landing on their head from multiple sources.
When in this situation they often take it all on and view their job is to just keep shoveling - trying their best to dig themselves out - all the while failing to meet anyone's expectations and not having very much fun.
While this might seem admirable it is ultimately ineffective.
Part of the Product Management role is to clearly communicate to all stakeholders (including the people providing resources) how much is on your teams plate and if you need more resources, time and/or prioritisation.
The most powerful thing you can do is say "No" as clearly and thoughtfully as possible.
You do this in multiple ways, including...
1. Be ruthless about prioritizating your backlog (in collaboration with your stakeholders)
2. Provide clear information/visualization for your stakeholders about what's on your roadmap and how long things will take to get done.
3. Push back against stakeholders who say "Isn't it easy to..." or "Can't we just..." and instead make it very clear what it takes to build and ship a quality product (using your roadmap as a tool for communication).
4. Insist that if your team is going to be responsible and accountable for more than it can handle, that you either get more resources or fewer responsibilities.
If the stakeholders around you don't understand or respect this process, then you're also free to move on.
Upon asking a colleague what being a product manager meant to him, he gave me one of the best answers I've heard.
P. R. D
Product managers will recognize that this acronym refers to an oft used tool of Product Management known as a Product Requirements Doc. It's the way that a PM shares the details/spec of the product that needs to be built with all key stakeholders (especially engineers).
In this context, though, he came up with:
I love this. An elegant way of repurposing the acronym to neatly summarize what PMs should be focused on.
It just requires a little bit of...
Oh and a little bit of...
Leadership and consensus building
Attention to detail
Long term discipline
But that’s about it...
Product is about nuance across multiple dimensions - context, intent, markets, personalities and more.
As someone who started out as an engineer, I’ve made the mistake of forgetting this over and over in my career.
As a (good) Engineer, you want to generalize things as much as possible. You want to look for common patterns and implement as few entities and workflows as possible.
An asset is an asset, right?
As a Product Manager you need to understand the difference between Persona A and B, Use Case A and B, Intent A and B etc. they can and should be very, very different.
Word choice, framing, UX metaphors etc should all radically change even while the underlying entities might remain the same.
The goal is not maximum system elegance/rationalization but, rather, maximum user understanding/alignment with their existing mental models and needs.
An interesting phenomena I’ve noticed when advising startups is the shallow understanding of what MVP means. Almost everybody uses the term now, but few understand how to successfully operationalize it.
It’s often difficult to determine exactly what the MVP is. It’s partly science and it’s partly art. The answer often requires a mix of experience and taste.
Often, after building the MVP, they continue to build more and more product without going deep on user acquisition and feedback.
Sometimes they build multiple MVPs of multiple major product areas leaving much of the product surface area in a largely broken state.
Remember, the purpose of an MVP is to get it into customer’s hands and learn and grow with your shared understanding. You need to continue to iterate and polish it until you can see your own face in the reflection.
Remember it’s “ship and iterate”, not “Build, build, build”. Shipping doesn’t mean just putting it on production. It also means putting it into customer’s hands at as much scale as possible.
Brand and product design can be such an important yet subtle aspect to your business success. It's easy to dismiss it as unimportant frosting on the cake, but investors, customers and partners can so often make split second decisions based on subconscious cues like pixel alignment and colors.
As a young startup, the things you must avoid include...
Biting off more than you can chew
Protracted timelines/scope creep that can blow out
Over engineering your solution before you know what your users really need
Poor/miscommunication between stakeholders
Over promising and under delivering
This is why MVPs and strong cross functional process is essential.
Reminder: If your problem is getting from A to B then the MVP is a skateboard (then a bicycle, then a motorbike, then a little hatchback, then a sedan, then a Porsche), not 4 wheels.
When working on product design:
First you want to get the "architecture" right (E.g. what are the core areas/screens/patterns)
Second, the UI metaphors (e.g. Are lists, feeds, carousels etc the right thing to do in each situation)
And finally, the fine grained details (is it 'your stuff' or 'my stuff', is it 'overview' or 'summary', is it 'done' or 'complete' etc).
All the data, opinions and ideas are the raw material piled up at the start of the process. Ultimately it’s up to you what gets packaged up and sent down the line for assembly (in the form of a PRD).
If debates are going on too long it’s your job to drive a decision, codify it into a PRD and send it down the line to design or engineering.
“Given that we have limited resources, what would you say is more important, that it looks good or it's technically accurate?"
As the product manager, your job is ultimately to make it both. The trick is to break the problem down into discrete product "moves" such that each move is both beautiful and functional.
The process is not to figure out what resources you have and then work backwards to something you can ship. Your job is to figure out what you believe the user needs and figure out how to marshal your resources to get you there.
Usually, that requires you to create a shared purpose and mission for your team, a reasonable roadmap of discrete releases/moves and the discipline and focus to keep everyone's eye on the prize.
If you feel like you have great product-market fit, and there's a large market of like-minded customers you can dominate: Listen to existing customers and continue to incrementally improve your product.
If you feel like you have great and growing product-market fit, but there isn't a big, profitable market left to conquer (or you've found yourself in a product/market you're not passionate about anymore): Sell to someone who wants to tap that market.
If you feel like you don't have great product-market fit and can't see a path towards finding it: Pivot, hard. Ignore existing customers and focus all your resources on the new direction.
As a Product Manager: You set the priorities and scope. Engineers set the date.
If you have a fixed date you need to hit, then you must de-scope until engineers feel comfortable they can hit the date.