Value creation is when you put 1 unit in and get 2+ units out. When you put in a sketch and get a high fidelity rendering back out. When you give some feedback and the spirit of what you wanted is translated into a final product that is as good or better than you expected. When the questions get answered correctly before they get asked. When you can leave something with someone and it just gets solved with minimum fuss and frustration.
When you get fast-forwarded to the future.
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.
The goal is not to win the “best technology” award. The goal is to win the “best business” award.
More often than not, a more effective sales and marketing operation with a simpler/easier to use product will beat the most comprehensive/powerful technology.
If you’re struggling to build your business around technology that most people don’t understand or can’t digest then consider going back to a blank piece of paper and building something very simple that is easy to understand and adopt. Even if that thing is not necessarily new or novel. Then expand from there.
Let’s call this the “gateway drug strategy”
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
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 design is so much fun!
Psychology + Art + Data/Science + Intuition + Invention
From an investor point of view, the way you word/frame the things you say can be more important than what you’re saying. Because by framing it well you’re proving that you understand how to navigate it well.
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.
Often going a little slower & more deliberately results in an increase in speed.
In your startup, you should be looking for collaborators who challenge your thinking.
This does not mean they are 'assholes' or devil's advocate just for the sake of it, but rather they are sure to delineate the risks (so that they can be managed), help reveal blind spots, and fill in the blanks in terms of your own skillsets and capacity.
In some cases these people should make you a little uncomfortable because they're giving you new data and areas of focus that you hadn't previously understood or considered important.
It's important, though, that those people are able to 'disagree and commit'. Once you make the call, they should get on board and work their heart outs to make your decision and vision a reality.
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
It’s not a startup until you quit your day job. Until then it’s a side project.
It’s not a product until users are onboarding themselves. Until then it’s a technology/prototype/experiment.
It’s not a business until your product is generating revenue.
It’s not truly scalable until you can grow users/activity/revenue without a corresponding growth in employees.
It’s not sustainable until your business is breakeven/profitable.
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.
Don't hire until you're absolutely ready to hire. Building a team to run an imaginary business just burns time and money.
You know you need someone to join your team when...
1. You, or someone on your team, is underwater and the tasks hitting the floor are holding the business back.
2. You don't have anyone on the team who is good enough to complete an essential and immediate task at the level of quality/effectiveness needed.
For example, don't hire a sales person unless you have a product to sell - and you've personally figured out how to sell it with the first few sales. Don't hire a growth marketer until you have a self-serve product ready to onboard and retain users. Don't hire a community manager until you have a product worth building a community around.
Noticing a trend? Build a PRODUCT that people want to use and is ready to scale before scaling your team.
It’s not enough to have an idea
It’s not enough to give it a name
It’s not enough to tell your friends
It’s not enough to dabble or do research
It’s not enough to build a pitch deck that clearly explains the problem, solution, market, business model, etc
It’s not enough to build consensus with key craftspeople (engineers, designers, sales, marketing)
It’s not enough to build a clear and easy to use user interface/user experience
It’s not enough to build a prototype
It’s not enough to build an minimum viable product
It’s not enough to ship it
It’s not enough to market it
You have to do ALL of those things - and much, much more. Consistently and effectively. And then iterate, iterate, iterate
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.
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...