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"
Product & Startup Builder
Filtering by Category: Product Management
Lean into meetings
"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?"
My answer:
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.
Why?
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.
Engineers Make Terrible Product Managers
Before you light your pitchforks, hear me out.
Entrusting the same individual with both engineering and product management roles is akin to having your quarterback also act as your head coach—it dilutes focus and compromises excellence in both domains.
Product management is a discipline of prioritization and vision. It's a game of chess where you're perpetually thinking three moves ahead. The role demands you to be a master of the 'what,' 'when,' and 'if' decisions, to navigate stakeholder politics, and to have an instinctive understanding of market dynamics. You're not just picking battles; you're defining the war strategy, marshaling resources, and ensuring morale is high enough to see it through.
Contrast this with engineering, a domain steeped in problem-solving and execution. Engineers are the vanguards of the 'how,' diving deep into codebases, algorithms, and data structures. They inhabit a realm of tangible solutions and immediate challenges, often reaching a 'flow state' that is antithetical to the interrupt-driven nature of managerial roles. Engineers are the infantry who scale the hill and plant the flag, all while the product manager is scouting the next strategic high ground.
The mental models, responsibilities, and skill sets required for each role are not just different—they're often diametrically opposed. While synergy and constructive tension between these roles can drive innovation, conflating the two often results in diluted focus and suboptimal outcomes.
Yes, engineers with a knack for big-picture thinking can transition into phenomenal product managers. But requiring anyone to wear both hats concurrently is not just impractical—it's a disservice to both the individual and the product. Specialization isn't just a nice-to-have; it's often the key to achieving excellence.
Software Doesn’t Sell Itself
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).
Product Strategy Is a Combination Of These 3 things
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.
The Difference Between Tech And Product
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.
Product Managers Need To Say ‘No’
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.
What Does Being A Product Manager Mean?
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:
Priorities
Requirements
Design
I love this. An elegant way of repurposing the acronym to neatly summarize what PMs should be focused on.
Product Management Isn’t That Hard.
It just requires a little bit of...
Empathy
Common sense
Oh and a little bit of...
Taste
Design skills
Technical understanding
Project management
Leadership and consensus building
Diplomacy
Pattern matching
Data analysis
Vision
Pragmatism
Attention to detail
Long term discipline
Experience
Passion
Curiosity/truth-seeking
But that’s about it...
Product Is About Nuance Across Multiple Dimensions
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?
Wrong.
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.
One Thing Product Managers Should Try To Avoid
As a product manager if you can avoid inventing something new to solve a problem, you've achieved something great.
So Many Startups Need To Stop Inventing Tech...
So many startups need to stop inventing tech and instead start building product. Others need to stop building product and start selling product.
What does MVP Really Mean?
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 Is Often Underestimated
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.
6 Things To Avoid As A Young Startup
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
Vague requirements
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.
Product Design In 3 Phases
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).
As A Product Manager, You’re Running A Factory Assembly Line
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.
Product Prioritization Through Clear Vision
“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.
As A Young Startup, Should You Listen To Existing Customers Or Pivot?
It depends.
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.
PMs & Engineers: Separation of Concerns
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.