It’s more fun to start designing and building an app than doing some user and market research first.
Unfortunately, though, that can be a very expensive mistake - both in terms of time and money.
Before starting, be sure to talk to (and survey) potential partners, competitors, customers etc.
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.
Often times, startups put off creating a pitch deck until they need to raise capital from Investors. Even then, they usually see it merely as a necessary evil in the process of fundraising. However, I've found that putting together a pitch deck can be a critical tool in ways that go far beyond fundraising.
How?
Because you (as a founder), your team, customers, partners, and other key stakeholders also need strong, clear and concise narratives that help get everyone excited, aligned and moving in the right direction.
For founders: A pitch deck forces you to turn often vague notions and visions into a structured, reasoned narrative.
For customers and partners: Developing strong, reusable decks allows you to construct a strong, consistent story that unfolds naturally and gets continuously updated to cleanly handle all objections. This process allows you to scale your core message across all salespeople. Ideally, the deck mirrors and fleshes out what's on the website and other self-serve materials.
For the internal team: The right kind of decks/meta-narrative that is updated and presented on a regular cadence empowers everyone to act and make good decisions without "the boss" in the room.
Reminder for VC backed startups regarding revenue, profitability and growth:
Typically, the goal is not to build a profitable business. The goal is to build something people/companies love whereby you understand the cost of growth (unit economics, revenue short fall etc) - and then fueling that growth as fast as you can with venture capital.
Over time, economies of scale, network effects and new revenue streams should make up the difference and blast you through to profitability at scale - or someone buys your big, growing and unique user-base for lots of $$
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.
When developing a strategy, be careful not to get caught up in any single tactic.
A strategy typically involves a number of strategic principles and focus areas. Tactics are the concrete steps you’re going to take to get there.
The Strategy is “we’re going to take that hill because it will be a great place to live”
The tactics are “we’re going to get 4 tanks, fuel them up, fill them with troops and go up the eastern side”
Also, as a leader, it’s your job to keep track of the big picture strategy while your team will get bogged down in the details. Very often they will confuse their focus area or passion project as the Strategy. It is not. You need to get all the moving parts right for any particular tactic to ultimately matter in the long term.
When thinking of sales/go-to-market for your software, it’s very easy to believe that it’s cheaper/faster/more scalable to partner with others to sell your stuff.
This is almost never the case. Channel sales (selling through others) can be a useful booster once you have your core sales engine running, but initially you typically need to do the hard work of finding your own customers and telling your own story.
No one else will be as effective, articulate or motivated to do it as you and your direct team. There’s no other way to get the learnings you need. There’s no better way to build direct connections and brand awareness in the market. There’s no better way to fast track your sales and control your own destiny.
Figure out who your end customer is and “call” them
If your sales or biz dev team is used to running the show, it will be very hard for them to accept a new, self-serve and scalable model. But accept it, they must. Scale you must.
Startups often make a number of key product mistakes over and over. Some that come to mind today...
1. Starting with too broad a "platform" trying to solve all categories/verticals/use-cases. E.g. "It could be anything!"
2. Starting with the wrong specific problem or niche vertical when there might be another niche that has more pain and money associated with it. E.g. Working to help gardeners get leads instead of helping lawyers (more money in the latter).
3. Starting with the wrong specific solution by not directly attacking the #1 sub-problem in the given market/use-case. E.g. Building a product to help lawyers write proposals when what they might actually need most is new business leads
If you're building & running a self-serve consumer app, you really only need to prove 4 things to raise capital and have a good exit
You can spend $x on acquiring a user and get $y in return. Where y is the Customer Life Time Value (LTV). It’s ok if Y is initially less than X (this is investing/subsidizing growth - see point 3).
The market your addressing is large enough such that your total revenue can become meaningfully large.
You have a clear and believable strategy to reduce the cost of X and increase the return of Y (This is essential if X is still greater than Y)
You have an IPO in your future and/or (more likely) you have a number of potential acquirers lined up - ideally you've started building relationships with them already.
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.
If you have too much on your plate (fires, bug fixes, feature requests) to find the time to do 2019 strategic planning while your hemorrhaging capital, then the ONLY thing you have time for is strategic planning for 2019.
Planning is not a distraction, a nice to have, or a way to find MORE to do. It's a way to find FEWER more FOCUSED and more ESSENTIAL things so that your time is better spent and your outcomes are maximised.
If no one is buying your product, it doesn't matter how smart/sophisticated it is. You must solve the top of the funnel first. You MUST figure out how to make something simple to understand and use that people will self-adopt.
If you have a great term sheet on the table, take it.
Pricing strategy is a very interesting game of psychology, unit economics and gamification.
In two sided marketplaces it gets even more interesting. There are so many counter-intuitive ways to get creative to drive the kind of demand and supply side behavior you want.
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.
In the early days of a b2c startup, doing bizdev activity for b2b2c distribution can feel so fun and gratifying.
It can feel like high-momentum, effective work that allows you to lock down glossy brands and partnerships who might get you big batches of users through the door. It also feels great to announce them to friends, family, media etc.
Often times, though, the reality is much, much different. Why? Because...
They often move very, very slowly.
They demand new features and behaviors that are tangential or orthogonal to your core product and business strategy.
They change their mind mid-stream
If you eventually get to ship the partnership/co-marketing program the results/conversion are often much, much smaller than you expect
If the results are marginal (which they almost always are at the beginning), your partner will often give up quickly and not put in the effort to optimise
For all these reasons, and many more, bizdev partnerships for a b2c app is really something to push off for later as a long-term bet and moat.
Instead, there's an axiom that says "Sell your own product'
Often times this feels like a harder, more data driven grind. However if you crack it (and you need to crack it!), it's high-scale, repeatable and has a huge, huge upside. It also forces you to really polish your product so that the user acquisition and retention really works.
You raise capital to trade money for speed & effective execution.
Executing a series of day-to-day tactical necessities without a strong product vision can only get you so far. At best it produces a confused and ineffective user experience. At worst it causes your team to spin their wheels, never quite shipping anything meaningful or polished.
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.