Have you written one of those “It’s Time to Embrace AI” memos to your team like we’ve seen go viral from Shopify, Duolingo, or Box?
How has that gone for you?
Best laid plans…
While everyone knows they should be using AI, changing behaviors is hard.
And learning a new skill and technology that’s unlike past generations of tools is even harder.
Yet, too often, founders and executives think they can just order their team to do it, and magically everyone will embrace AI and get all the benefits we hear hyped online.
I recently worked with a client helping them improve their AI adoption. There I saw even smart, capable people weren’t using AI very often beyond some basic questions to ChatGPT. I learned the real problem isn’t awareness nor desire; the reality is it comes down to problems like time, uncertainty, and trust.
Today’s post breaks down what worked (and what didn’t) in helping a team move from curiosity to consistent AI use, and gives you practical approaches to apply to changing the AI culture at your team, whether you need to get everyone, or a slow adopter or two, on board.
One of the biggest complaints I hear from people about not starting a company, who otherwise have the skill, ambition, and desire to, is the fear of losing health insurance.
If you have a family, it feels reckless and dangerous to go without health insurance for you and your children. And even if it’s just you, you’re still one car accident, one bad tackle, bike crash, or another surprise medical event from disaster.
Yet, the other side is just as bad. Who can afford to start a company and pay $20,000+ annually in premiums alone to insure your family, all before you cover your co-pays, a massive deductible, and an even higher “max out of pocket” amount if anything bad happens?
That’s why I think it’s so helpful and important to know about a real, viable alternative I found.
Something that can save you literally 3-5X over the cost of your health insurance, and that I know really works, because I’ve used it for 3 years now and have been convincing many friends and family to use it, too.
CrowdHealth: An answer to your health care prayers.
You’ve probably never heard of CrowdHealth, and that’s okay. I didn’t know what they were either until I was at a Bitcoin meetup and the CEO was on a panel talking about sovereign health and how you can opt out of the corrupt, bloated, overpriced health care system.
Running a startup puts a ton of responsibilities on your plate. From marketing to sales, hacky-HR to accounting, development to project management, you’re wearing a million hats.
The same can be true for Product Managers. You can find yourself involved in many projects, tons of meetings, and more competing priorities from your stakeholders than you’d like.
Yet, through all this busy-ness, whether you’re an early stage founder, or a product manager, you need to make time to talk to customers. It’s the lifeblood of building something people want, getting to Product-Market Fit, and launching successful new products and features.
As you commit yourself to “getting outside the building” to talk to your customers, it’s essential you make the most of those discussions.
Talking to customers…but how?
One of the hardest things for newcomers to customer development and product management to get right is the questions they ask in their interviews.
Done well, you can learn priceless insights that help you prioritize and build the right things, while descoping things that turn out not to matter. Done poorly, you fail to get sufficient signal across interviews, and waste you and your customer’s time.
Fortunately, I’m here to help you today.
I’ve taught dozens of product managers and founders this process hands on (and thousands more through posts like these), and it’s led to fantastic results for them. By using this structure, you avoid biasing your customers or putting them on the defensive. You also maximize your learning so that you can get the best insights in the fewest number of interviews.
With that in mind, let’s dive in, so you can learn how to have great customer interviews, too.
How to Structure (and get the most out of) Your Customer Development Interviews
The biggest mistake I see otherwise well-intentioned founders and PMs make is that they come to their customer interviews with no preparation.
Showing up and just saying, “Tell me about…” or “What do you think of my demo/product?” is a huge missed opportunity; you don’t know what you don’t know at that point, and lose out on a lot of great insights you could learn if you asked the right questions, in the right order.
Ask the right questions at the right time.
You can make a great impression and learn a lot more by following this simple, 3-step process I share below: 1) People, 2) Problems, and then 3) Your Solution.
A few quick notes before we break those down:
Timing: Depending on the person, this question flow generally takes 30-45 minutes to go through. If you can get a customer to agree to a 1 hour call, that’s ideal, but you can prioritize the best questions if you have only 30 minutes.
Business Model: This structure is best suited to B2B customer development, but with a little creativity, you can definitely adapt this for B2C interviews, especially if the B2C product involves the customer making a direct purchase (i.e.- subscription or e-commerce).
Order: This order (People -> Problems -> Your Solution) is extremely intentional. You must go in this order, or it will hurt your results of your interviews. More on why later in this post.
With that in mind, let’s take a look at the 3 sections, in order:
1) People – Aka – Who Are You Interviewing?
Before you get into anything about problems, or your solution, you need to figure out who you’re actually talking to. This both warms up your interviewee with some softball questions and gives you an opportunity to build some rapport with them.
It also helps you get to know them and the parts of their life around the edges of the problems you’re potentially solving for them.
Important: Do not shortchange this opening section of questions!
You don’t need a novel on their daily life, but you *do need* enough to be able to understand their role within their company, who key players are, and a general baseline of their sophistication.
All of this will help you later pattern match who the user type that is most receptive to the problem you’re solving and the solution you offer, as well as who is not a fit. This is priceless for your product, your marketing, and your sales processes.
Some example questions you can ask:
What is your name and role at your company? (If you can find this out in advance, always look it up to save asking the question)
How do you fit into your company’s department structure? Overall in the company?
How do you discover new products for work? Do you need any approval to try them?
Have you tried anything new recently? How did it work for you?
What is a typical day like on your job?What are you main routines?
What is your budget like? Who has to approve your purchases?
How much time do you spend doing [task X]? (Task X being anything they mentioned in their typical day that stood out to you or related to your product/business)
Pro Tip: When you’re preparing for your interviews, give yourself a section before your People questions to fill in things you can look up on your own.
This can be things like: Their name, Job Title, Company Website, Linkedin profile, Company name/size/industry, location, internal analytics profile from your company, and anything else you can find out about them that shows context about who they are and their behavior in your product.
Then, add any questions to your script that come to mind as you gather this info to really make the most of your interviews like their usage of parts of your product, unusual things in their profile, etc.
Going into these interviews, I never know which aspects of getting to know them will be the key, which is why adding the extra notes beforehand helps; you’ll be looking back at all your interviews to figure out what common patterns and differentiators are.
2) Problems – Aka – What are your greatest pains?
This section is where you try to find out whether the person has the problem you believe you’re solving. Your goal is to not lead them to your problem. The less you lead them while still hearing your problem being mentioned, the more validation you have!
People love to talk about themselves, so let them go nuts here and really rant about their problems (i.e.- Shut up 🤐 and listen!). Generally, people are terrible at proposing solutions, but you want to hear generally what they envision as solutions or see what they’ve cobbled together themselves.
Some sample questions you can ask:
What are your biggest initiatives and goals right now? How are they going so far? (To understand their priorities and which they need help with most)
What are your top 3 challenges you face in your job right now? Why did you choose those? Why that order?
What are your top 3 challenges you face in your job related to [industry X]? (Industry X being the one your startup/business is in)
If you could wave a magic wand and instantly have a solution to any of those problems…what would the solution be?
Dig deeper into their typical day on anything that sounds painful or expensive. (You can add some hyperbole here to get them to rant a bit by saying things like “that sounds inefficient…” or “that sounds expensive…”)
How have you dealt with or solved [Problem X] so far? (You’re looking to find out if they’ve hacked a solution together themselves. If they have…ask for a copy of it!)
How does your work in this area interact with your coworkers? (Look for collaboration problems, needed features, and others you should interview)
What do you have to report to your manager or other teams related to this? (Look for reporting needs, buyer expectations, and how this problem may impact others)
Notice, you haven’t mentioned your solution, nor problem yet. If they don’t mention your problem specifically, then as you finish this section of questioning, you can directly ask them if what you think is a problem is a problem for them. Whether they agree it’s a problem or not, you want to then probe why it wasn’t one of their top problems.
The beauty of this approach is that you’ll learn a lot about their day to day, and what they perceive as their most pressing problems. This can often help refine what you’re working on, or reveal a pivot that can change the fate or trajectory of your business.
3) Your Solution – Aka – See if your idea survives customer interaction
In your discussions in part 2, if your interviewee brings up your problem you think you’re solving, then you’re on the right track! Bonus points if the way they describe solving it with their “magic wand” remotely resembles what you’re doing.
No matter what happens in part 2 you should discuss with them what you thought the problem was and what your solution is. Getting validation that they wouldn’t be interested in the idea is just as helpful as finding out they love it; either they’re not a customer, or you are learning what your customers want instead.
Some sample questions you could ask:
Walk them through the problems you believe your solution solves. Do they agree?
Does [your solution] solve any of your problems?Why or why not?
What looks most helpful or important to you?How will that help you?
What’s missing from what I’ve shown you to help solve your problems? Why is that important to you?
How do you see this fitting into your routines? What would be important to make it fit well for you?
Who else on your team, or at your company, would be interested in this?How do you think it would help them?
Would you be willing to pay for our solution? What budget do you have for something like this? (Don’t be afraid to probe for the pricing you know you want…”Would [X] be reasonable?” It’s imperfect but gets you started.)
If they’re willing to pay for your product and like the idea then… “Would you be willing/ready to start right away?”
If all goes well and you really are solving a pain, then your customer should want access to your product or new feature right away. More likely, you’re going to learn a ton about what they do and do not want and your idea will begin evolving. You’ll also find out others at the company you may want to talk to that have needs if your customer will start using your product.
Keep in mind: The way you present the solution can be flexible for the state of your business or the development of this feature:
Describe it in words: Tell them what you have in mind, or sketch it on a napkin or paper.
Show them mockups: Share your screen or turn your laptop/tablet towards them to show what you have in mind.
Send them a clickable prototype: Especially if you’re interviewing them on video, sending a prototype link is a great way for them to see and feel what you have in mind. (In that case ask them to share their screen and narrate their thoughts as they go through it)
Give them staging or feature-flagged access: Once you’ve launched, this is the most powerful because they can try it exactly as you intended. (And again, have them share their screen and narrate.)
In all cases, the goal is to give them something they can react to. Don’t let the simplicity of what you have stop you from learning.
In fact, you can learn a ton in these interviews when you literally have nothing to talk about in the Solution section; I’ve launched products and new features multiple times where the first round of interviews had little to no solution discussion, and we only followed up later for solution-focused feedback built on what we learned in the People & Problem sections.
Making the most of your customer interviews
This basic structure can carry you a long way towards some great validated learning about your idea and your market’s desire for it. It can help refine your idea or feature, help you determine if you should pivot, and reveal new opportunities that can help you grow faster.
There’s a few more things to keep in mind that I’ve learned over time. Applying these tips can help you become a real pro at interviewing customers.
1) Take good notes and record everything!
Once you’ve interviewed 8-10 people, you should be going back over all of your notes and look for patterns. This includes especially looking for patterns in the Part 1 section to see what all the people that agree you are solving their problem have in common.
Summarize your notes then and share with your team, so everyone benefits from what you learned, and you can iterate together on your solution based on what you learned.
In particular, having a recording (and more recently, AI transcription) can really help here, because then you can re-listen to and review great interviews, as well as share snippets or the whole interview with your colleagues.
2) Have other team members sit in on some interviews
A good customer development focused company will have everyone involved in the process. Performable, pre-HubSpot acquisition, had their engineers spending 30% of their time on the phone with customers. Nothing helps someone do their job better like understanding who they’re building/selling/marketing for.
Using a script like this should not feel like an interview! They should feel like they’re just having a conversation with a friend about their problems at work. The more comfortable they feel with you, the more they will open up. This is part of the value and intention of the People section of questions.
By preparing your interview script in advance, you can more confidently run your interviews knowing exactly what you want to talk about. Be sure to use language that feels comfortable and natural to you, and don’t be afraid to iterate on any questions that aren’t getting the response you hoped.
4) Go off script
The best insights comes when you dig a little deeper on something that strikes a chord in the discussion. The script is there to be your roadmap, but there’s no reason you can’t return to it after a 5 minute digression about a specific pain, or discovery about how the company operates.
5) If they’ve made an MVP…ask to see it!
Nothing gives you more insight to a customer than what they’ve hacked together themselves to solve a problem. The best thing you can do is ask to see it, which will give you an idea of what they’re hoping your solution will provide. These people are also the strongest candidates to be great, helpful early adopters of your product.
If the hacked solution is actually a competitor’s product they’re frustrated with, ask them to share what they love and hate about it; that’s just as valuable as any hacked or cobbled together solution.
6) Always follow up
It’s common courtesy to thank people for their time and help. It also opens the door to follow up with them in the future if your product changes and is a fit for them, or to invite them to try it out when it’s live/launched.
Also, if you promised a free gift card (or other compensation) for their time, be sure to keep your promises and send it to them promptly. And if you hear about any bugs they report, be sure to fix them and then let them know.
All of these things score major points and make a great impression, which will make it easier to get people to interview in the future as well as build good will with current and future customers.
7) End with an ask
Always end your interviews by thanking them and asking them for something. It may be to get a copy of their MVP, or even better, ask for an intro to someone they know that might be interested in what you’re working on.
In my experience, these intros have an 80-90% success rate in becoming new customer development interviews, whereas cold emails asking customers you’ve never spoken with only have a roughly 10% success rate.
8) Be open to new problems! That’s how great products are born.
As Steve Blank has said, “No idea survives first interaction with a customer.“ Don’t be afraid to shift your focus from your first idea to what you’re actually hearing customers want. If you probe in part 2 and find a burning problem…find out how they currently solve it and what they’d pay to solve it.
Sometimes these shifts are subtle, because what you thought was most important is secondary to a bigger problem. That’s when you tell marketing and sales about a shift in positioning.
Other times, this is a huge shift and you need to change what you’re building significantly. That’s when you should have a bigger team-wide discussion.
Either way, having detailed notes, recordings of your calls, and some examples from customers of what they want instead can be the difference between what you found falling on deaf ears, or being embraced as strong evidence of a change in focus or full blown pivot being necessary.
—
In the end, you want to find a “hair on fire” problem, not a “nice to have problem.” Think about it this way: If my hair is on fire (literally), and you’re selling buckets of water, I’m definitely going to buy your product. But if I’m cold and wet, I’m not likely to buy your bucket of water right now, but might consider it in the future.
Find customer pain and a solution they desire and will pay for. Rinse. Repeat.
From launching your first product, to adding the nth feature to your company’s product suite, interviewing customers is an essential skill. By using the People -> Problem -> Solution framework and being well prepared for each interview, you can spend more time building the right things and less time adding things that no one cares about.
Further Reading:
Looking to truly master the art and science of interviewing customers? Read these other posts:
Do you find your product team doesn’t want to read your specs? Do others find them a lot less clear than you think they are?
Are you and your engineers missing estimates, or struggling to ship on time, because of changing requirements and surprise details changing context mid-build?
If you’re having trouble with things like missed deadlines, confusion and miscommunication mid-project, and not shipping your best possible work consistently, then it might be time to take a hard look at your product specs. They’re likely a big part of the problem.
The Product Thesis: A Better Way
Early in my career I was kind of winging it when it came to planning with my engineering and design teams. I had all kinds of documents all over, and I was inconsistent in the process from sprint to sprint and project to project.
Not surprisingly, it showed in the results we got, and the problems we had.
Fortunately, when I joined KISSmetrics, Hiten helped me learn a better way by introducing me to Josh Elman, who worked on product teams at Twitter, Facebook, and Linkedin. Josh taught me about the Thesis, which is a lightweight, efficient way to communicate all the essential details your product team needs.
It led to engineers and designers actually reading what I wrote in my specs, better ideas coming from everyone, and ultimately shipping more wins faster. It really was that transformative.
Now that I’ve used the Thesis on dozens of projects of my own, taught it to many of my clients, and tweaked it based on what I found worked best across many situations, I’m going to teach you how to write your own thesis for the next feature or product you build.
The Better Product Spec Alternative: How to Write a Product Thesis
By using Josh’s Product Thesis, I solved a lot of the problems I had, and similar ones I see with my coaching clients:
Hard to find everything: Too many docs in too many places means key info can’t be found or is missed. The Thesis represents one place for all the most important answers for you, designers, engineering, and other stakeholders.
Too long, didn’t read: Most people do not read 10+ page documents. The Thesis and its bullet driven structure forces you to get right to the point. My average thesis (excluding further reading) is only 2-3 pages, which led to everyone reading them.
Missing key info: Compare the list of areas below to the product spec for your recent work. In my experience, most PM’s specs are missing roughly half of them, which is a missed opportunity for better, clearer planning and organization.
Being Solution, not Problem-oriented: Too many specs I review are dictating outcomes all the way down to button placements. The best solutions come from discussion and debate with your engineers and designer. A thesis becomes a primer for solution discussions to ensure the most important & impactful opportunities are tackled.
When you pull all this information together in one, brief, easy to read place, it helps your product team better understand the why behind a feature and come up with the best solutions together. It helps motivate them more as well, because it helps them really taste and feel customer pain and opportunities.
When should I use a Product Thesis?
There are two simple things to keep in mind to determine if you need to pull everything listed below together for a Product Thesis:
1) For all significant projects
If a project or task will take less than a week’s time or fits in the “Quick Win” category of a simple ticket or two in your project management tool, then you do *not* need to make a Product Thesis.
Meanwhile, if you know for a project there will be:
An Epic in your project management tool to tie a bunch of tickets together
Enough design changes you know you’ll do some major user testing
Any major changes to workflows or processes
The project is a key part of your OKR/Quarterly roadmap
Then, those are exactly the times where pulling all of the things you’ve learned about the project and opportunity into a Thesis is the right move.
2) Before you start thinking or talking about solutions
It’s sooo tempting to start thinking about what you could do for customers. Yet, you shouldn’t do that. Pull back.
Instead, you need to pull all the information about the problem together for you and your team in your Product Thesis so that you have the guardrails for a deep discussion with your designer and engineers about:
What’s possible to do?
If we could wave a magic wand, what would we create for our customers?
What can we get done within the time constraints and budget we have?
What quick wins could fit in related to this?
What should be de-scoped because it’s too hard?
Design and tech debt considerations that come into play.
You only get the magical alchemy of building incredible products when you include your design and engineering team in the solution process. It’s what both Steve Jobs and Marty Cagan do.
And they and you can only combine to come up with the best solutions when you set the table with all the information everyone needs to truly understand the problems, opportunities, and constraints. It also engages and motivates them much better than dictating solutions to them.
Knowing all of this, let’s dive into what actually goes into a Product Thesis.
Want a FREE Product Thesis Template to use on your next project?
Sign up now and I’ll send you the template I’ve used for 10+ years:
What goes into the Product Thesis?
Below are the sections with explanations for why they’re each important. If you have any questions about any of them, please leave a comment on this post. You can also listen to this podcast discussion on the Thesis I did years ago as well if you like audio.
Remember: Stick to bullets! This should ideally be 1-3 pages long as that ensures that your team really reads it and can engage quickly. You can write up a separate memo like the Amazon Press Release style for marketing and other stakeholders after you and your product team have settled on the solution & scope.
The goal here is to clarify your thinking, make sure you didn’t miss anything, and set the stage for a great discussion with your engineering and design partners on what is possible within the constraints and opportunities you outline.
To this day, 15+ years in my career and over 10 years since that fateful meeting with Josh Elman, I still start every Product Thesis I write by copying a template like the one you can sign up for on this post.
Okay, here’s the sections of the Product Thesis and why they matter:
Product Thesis Title Here
1) Why are we working on this next?
This is first for a reason: This is what gets others excited and bought into what you’re building.
Every company, and especially startups, are resource constrained. What you choose to build affects your company’s bottom line, your standing in the market, and what your team thinks of your judgment.
You need to succinctly get everyone reading this on board to why this is the biggest problem or best opportunity.
I try to have a mix of qualitative and quantitative data here including:
Mandates from the leadership team to focus on this area
How sales needed it for a big customer, or how many customers are begging for it
A stark number that paints the clear picture and creates urgency (like an alarming churn rate, big dollar value deals the feature is for, or clear weak points in a key funnel)
The more your designers and engineers can understand why this matters, the more interested they will be in working on it, even when it’s not the hottest new tech or feature.
2) When and how do people use this feature?
Most products end up having a variety of different users and ways that people use the product. To help your team better design a specific feature for the right part of your customer base, you need to detail who this new feature is for.
Be specific! A use case section that is just something like, “As a marketer, I want a mobile app so I can access my data away from a computer” is total weaksauce. Instead, provide the kind of context and detail that paints a picture of the situation:
“On their way to work on the subway, content marketers like to check how their blog traffic is doing for items they published that morning or the day before. It helps them get into work and know how they’re doing before they sit down. If a number is low, they may try promoting it extra to try to raise the number. If the number is high, they may share the win with others on the team.”
Could you picture that situation in your mind? Can you see Jenn the marketer opening an app on her iPhone while sitting on a subway car? I bet you could. Your team can, too. They can also then start thinking about what the perfect (not just good) solution would be for them.
Write out as many use cases as you feel are needed. I often have as many as 4 or 5 detailed cases for a big feature, especially when our product has multiple personas.
3) What Problems do we need to solve? (in order of priority)
Features are really solutions to your customer’s problems. It doesn’t do any good to build a feature that doesn’t actually solve the problem, so it’s important to detail what problems you need to ensure the solution your team creates addresses them.
Problems should either be existing problems your product has (especially if you’re iterating on an existing feature) or the problems related to the use cases you just described above. Some example problems may be:
Performance Problem: Customers are experiencing frequent crashes (57 incidents last week). This feature is critical for customers and they are constantly having to refresh and start over, losing their work in the process.
Design Problem: 20% of support tickets are due to customers are having issues with the current UI. They can’t find key features that exist that they say are important to them (Include a markup of the interface to show these.)
New Problem:Customers spend hours every week manually copying numbers to a spreadsheet and making their own visuals for their VP. If we automatically make those reports, we’ll save them time and can then have the VP see our branded reports frequently.
I usually write out 5-7 problems that a feature addresses in bullet form. If it only applies to some of the use cases I described, I’ll specify that as well.
Remember to also rank the problems, so that the most important issues get the most attention. When ranking, remember Olsen’s Hierarchy of Needs as a helpful framework on what matters most: (Note – the bottom is most important like Maslow’s Hierarchy)
This ranking matters most when it’s time for tradeoffs. A detailed ranking of problems will help you make sure the right things get done and avoid being de-scoped, while less important, and difficult items quickly hit the chopping block.
4) How much time is budgeted for this project? When do we need to be completed with this by?
One of the additions that I’ve found has been important for most product teams, but wasn’t in Josh’s original lesson for me was to call out the time / budget for a given project.
This is important to think about for 3 reasons:
Your engineering and design teams need to know how big a project this can be, so you can talk tradeoffs and scope effectively with them as you collaborate on coming up with the best solution for this phase of the project.
You are consciously choosing how long you work on this project versus the other potential projects and goals you have. You have finite time and resources, so you need to decide what is worth the largest investment. RICE and similar frameworks can help with this, as well as thinking about these kinds of tradeoffs:
Your stakeholders need to know when you’ll deliver this project, so they can plan accordingly for how they’ll act based on this launch.
In particular, sales and marketing teams can become very frustrated by majorly missed deadlines. It not only impacts their planning, but it critically affects their ability to hit their numbers.
The simplest way to avoid these kinds of issues is to start making the time allotted for a project something that is defined at the earliest stages of planning. That’s why in this section the goal is to very succinctly, in 1 sentence in 1 bullet define:
How many weeks you have for this project and a target ship date (or time when it’s in QA and ready for your deploy process.)
Yes, you may want some flexibility depending on what you decide is important, and that’s exactly the point; time spent on this project should be an active part of the discussion. Otherwise, I’ve seen too many cases of projects that run much longer than planned, or scopes that get completely out of control, preventing essential other projects from happening.
5) What are Future Considerations that must be accounted for?
This section is all about avoiding hearing from engineering, “I wish you had told me that before we built [X]!”
Very often, when engineers build something, there’s a few ways they could do it. When you give them a hint of what may come in the future, or that was de-scoped early in this process, they can make more intelligent decisions about how they build things now. A small change now can make a revisit to the feature *much* easier 6 months later.
Depending on the feature, this could be very short or long section. If there are things you know are not going to make the first version of this feature, but expect will be needed to be added later, be sure you tell your team!
You can also use this section to note things that originally were planned for, but after discussing with your team, you de-scoped. This is how you turn your Product Thesis into a living document that is useful to reference at many points in your product development process.
The bottom line: Balancing the present and the future is a constant struggle for your product. The best thing you can do for your team is give them the key information you know so they can do their best to balance their work against the present and future as well.
6) (Optional) How does this tie back to this quarter’s OKR(s)?
This should be a single sentence explaining which of your OKRs this project relates to, why it does, and a link back to your OKRs document or tool.
The point of this is to make it obvious to anyone seeing your Product Thesis how you see this contributing to your OKR(s).
If you don’t have OKRs, obviously ignore this section. You can also include this in your Why section in the intro if you prefer, but I’ve found that explicitly calling it out like this is helpful for others (like say an executive or your boss). As with everything in the Thesis, use your best judgment for what fits your team and company.
7) What is our KPI or Metric for this Thesis?
This is one of biggest gaps in most product specs I’ve reviewed, and it’s critical that every Thesis have some form of this.
You should ask yourself, “What would make this new feature a success?” A KPI (Key Performance Indicator) is the most common way to determine that success since ideally you will tie the success of the feature to one or more of your company’s key metrics.
It’s okay to have more than one KPI, but keep it simple, or there will be too many things to measure. When I’ve had multiple KPIs for a feature they’ve been things like:
Support requests will drop by 90% for this feature after relaunch.
Usage of our app’s [X] feature will grow by at least 50% after relaunch.
Because this feature affects the sign up flow, we expect a 5% lift in conversion after this launches.
You will fail sometimes, but by forcing yourself to quantify what you expect to happen, you will keep you and your team honest. By setting a number that you must hit, you can also know when you should go back and iterate further. You’ll also hone your instincts on what creates wins and what does not.
Further, by identifying the metric up front, you make sure any tracking that needs added to the product is done while your engineers build it, saving them time going back later, or lacking a baseline after launch.
Most important for this section is simply the act of committing to measurement. Shipping is not success as a product manager, but without calling out measurement in your spec, I find most PMs never get around to measuring a lot of what they should for their features.
8) Who are the stakeholders and how/when do they need to be informed?
When work gets busy, it’s easy to forget about stakeholders and other people you don’t work with every day. That’s how you end up forgetting to loop someone in when they need to be.
This can end up hurting you and your company in a variety of ways:
Your launch may flop, because marketing had no time to prepare a press push or launch announcement.
Sales misses out on some deals, because they don’t know what is available soon enough to close a key, tightly fought deal.
Other teams may step on your toes, because they didn’t know what you were working on.
Avoid shooting yourself in the foot by thinking through who you need to involve in this project and how. Keep it simple, much like the OKR section, by simply:
Listing out the Name, Department, and when and how you expect them to be involved in the project. One name per bullet.
Then, make sure you stick to that plan, and confirm with the stakeholder you agree on how they’ll be involved and what they need to know.
This is a checklist to remind you who to speak with and helps you make sure you give them all the time and information they need to coordinate with you effectively.
9) Further Reading:
Your main document shouldn’t be longer than 2-3 pages, so Further Reading can act as an Appendix for you. This section allows readers to easily jump into an area that is most interesting to them and see the data or evidence that backs up your Thesis bullets.
Add links to customer research, call recordings, feedback, quotes, usability testing, surveys, survey analysis, specific analytics reports or queries, etc. While your main document should be no more than 3 pages, Further Reading can be as long as you want.
Remember: You want all the detail you can without the fluff and verbosity that makes engineers and designers skip reading it. Further reading is a great place for specific information that didn’t fit in the above sections and may be relevant to only certain team members.
Who should I share this with and when? How do I use this with Stakeholders?
The number one goal of this document is to help you bring clarity of thought and a clear definition of the project to set up a healthy discussion with your design and engineering team. Together, you’ll work out what the best solution is based on the constraints, problems, and opportunities here.
The secondary goals of this document and process is to:
Help you identify weaknesses in the work you’ve done to define this (i.e.- Don’t know something? Go find out.)
Start thinking ahead for how to involve marketing and other stakeholders at the right times.
Give you an organized place where you have all your research and thoughts in one place, so you can share all or part of it when it’s helpful in stakeholder discussions.
This then makes it easier to share with other colleagues when it makes sense. Once things are solidified with your core product team, it often can be helpful to share your Thesis with some of the stakeholders you noted in section 8; the same use cases and problems that inspire your designer can also inspire marketing copy or sales pitches.
Conclusion: A great Product Thesis is a high leverage asset for PMs
Creating a great product spec clarifies your thinking, organizes it clearly for others, and helps you avoid many of the most common pitfalls of the product development process.
The best way to ensure your product specs are consistently high quality is to use a template to guide you. That way, you don’t forget anything, and others get used to a consistent format from you.
If you’d like to upgrade your product specs, and want to start using the Product Thesis, I have created a template you can use now. Simply enter your email below to receive the template straight to your inbox:
I’ve been working on SaaS products for nearly 15 years, which feels kind of crazy to write. While I’ve worked on a lot of very cool products and helped many other PMs over the years, it doesn’t seem like it’s been that long.
What lessons have I learned?
The other day, a friend asked me what rules I’ve learned that I would apply from day 1 the next time I start a company. It got me thinking, and once I jotted my thoughts down, I realized it was worth sharing as a post here.
There is no need for a lengthy preamble, so let’s get right to them.
10 Lessons for Scaling Your SaaS Startup Faster
Consider this a checklist of simple tactics and approaches that I’ve seen first hand work repeatedly. Maybe your situation is different, but they’re all worth at least experimenting with, and very likely moving up your priority list to do sooner.
Many of these I learned the long and hard way, and wish I had done sooner, which is a big part of why I decided to write and share this post. It’s the kinds of things I coach my clients to think about regularly, so this is also a reference for them in the future, too.
I hope you learn a thing or two, and make a few extra dollars faster because of them.
1) Start charging as soon as you can. Earlier than you think you can.
One of the greatest mistakes I see founders make is to wait to charge money for their startup. It crushes me to see friends and mentees waste months, or in some cases even years, of their lives building their product for free, avoiding the hard question of, “Will anyone pay for this?”
The fact is people will use a lot of things when they’re free that they’d never pay for. And equally important, you don’t learn many key things when you put off the discussion about them paying:
What is their buying process?
What kind of budget do they have for this sort of problem?
Is this problem important enough that they’ll pay for it?
Can your user even make buying decisions?
Will they pay enough for this product to make your business viable?
In one particularly sad case, a friend of mine went years without charging for his product. In the process of chasing the mythical startup where he’d charge based on progress next month, he not only ultimately had to shut down the startup, but he destroyed his personal credit, his wife divorced him, and he lost custody of his daughter. I wish I was exaggerating any of that.
Don’t be a cautionary tale. Cross the penny gap as soon as you can.
I’m still amazed that I got customers to start paying for my startup, Lighthouse, when we were a barely functional CRUD app. You could post some notes, and we sent a morning reminder email, and that was it. Yet, people not only paid, but my second customer ever actually prepaid annually. Quite the vote of confidence.
The Bottom Line: Start charging customers before you think you can. Often, you can even get them to pay *before* you build anything. But you won’t know unless you ask.
2) Offer annual subscriptions from day 1.
Now that you know you should start charging as soon as you can, and earlier than you think, the next move is to have an annual plan.
You may be surprised to realize that many people prefer annual agreements; it’s standard for procurement departments, and if you need reimbursement or approval to spend money, you only want to go through the hassles once a year.
And that’s before you get into basic persuasion.
The single most profitable, highest impact experiment we ever did in the history of Lighthouse was an email we sent to customers.
After 3 months of them paying monthly, we sent an email that essentially said, “Looks like you’ve been enjoying using Lighthouse. Why don’t you save yourself some money and buy an annual plan?” Our annual plan gave them 2 free months, and that’s all they needed to think it was a no-brainer to pay annually.
Some founders I’ve met are afraid to offer annual plans up front, and to some extent, I thought people wouldn’t want to. But the fact is, if you offer it, some will say yes, and if they say no, you’ll learn helpful things anyways.
The Bottom Line:Offering an annual plan can help you grow your revenue much faster. Especially if you’re bootstrapping, this can provide critical rocket fuel to fund and grow your business, all while lowering your churn rate (they can’t cancel for 12 months, after all).
Apple makes a little bit of money from services. Can you? (SOURCE)
3) Charge for services you provide. People will pay.
You’ll notice the first two tips are all about helping you make money faster. This third one is also about money, too.
The fact is, you need revenue to grow your business. It’s the oxygen to keep your business going. (Obviously.)
Investor capital only goes so far, and getting that next round of funding is usually related to how much revenue you were able to generate with the last round of funding.
And if you’re bootstrapped, more revenue lets you quit your job sooner, or fund more growth faster.
Either way, more revenue sooner is a net good thing.
Yet, some people frown upon services revenue. They think charging one time costs for things like setup, training, manual work, custom integrations, etc is a bad thing because it’s not recurring revenue.
However, if you look at lot of successful publicly traded SaaS companies, services revenue is a real part of their total revenue each year. No, you don’t want it to be 90% of your revenue, nor do you want to become a custom development shop for anyone, but you can easily make 10-20% of the value of your contracts include one time services revenue. This is on top of whatever your annual subscription rate is.
This is awesome for you for a few reasons:
It’s free money on top of what you expected to make: You probably have to do the things you’ll charge them services revenue for anyways. Now, you’re making money for doing it. If it’s a $10,000 or greater deal, they probably expect it, so why not ask for it?
It’s a second negotiating point & an easy place to discount: Procurement is usually rewarded for saving money on the total contract, not necessarily an individual point. That means when they negotiate, you can discount the one-time, services revenue, while preserving the price of your recurring subscription. You can also use tactics like telling them you’ll waive it if they close today.
Renewal time is easier: While in year 2 you may have less services to charge for (or none at all depending on what you provided in year 1), you’re hopefully growing your subscription fees. With the services price down in your contract, you can often then grow your MRR in year 2 without substantially increasing the total cost to your customer. This is win-win as their books look better, and you show growth on your side.
The Bottom Line:Services revenue is your friend. It’s free money for any deal you’re negotiating of reasonable size, and you can ask for it as soon as you start charging customers.
4) Use software to make yourself more efficient.
One of the great breakthroughs of the last decade is how software has been eating the world; there’s now software to help you do just about everything. This saves you time, money, and allows you to do more with a smaller team than was ever possible before.
It’s amazing to me how much my team and I have been able to do never being more than a team of 7, thanks to the fact that virtually every department has software to help support it.
A few of my favorites include:
Intercom: Covers all of our help docs, customer support tickets, in app messaging, product tours, and chat on our marketing site.
Gusto: Simple payroll so I never have to think about paying employees or contractors, nor worry about tax time.
Upwork: For easily finding high quality, inexpensive workers in other countries. Takes care of paying them, monitoring their work, and helping you run an efficient hiring process each time.
Digital Ocean: So easy to use that as a non-technical CEO, I can go in and make upgrades and check or fix things in a bind.
Strikingly: Simple landing page tool, which has allowed us to build landing pages that look great even with no designers or engineering involved.
Stripe: The easiest payment processing setup I’ve seen, that makes it easy to manage your subscriptions, handle refunds, and use across multiple offerings you have.
And I could list out dozens more, all of which combine to save us time and money.
Over the years, I’ve embraced this idea more and more, which has led to a few simple rules for adding software to our stack:
Anything that costs less than $50/month is a no brainer: Any team member can ask for the company to pay for a tool at that price or less. If it helps them do their job, it always pays for itself. All I ask is what it is, and an invite so I can enter the credit card.
With a strong case, most other tools still are purchased: Above $50, we have a quick discussion about it. The team member requesting it has to help us calculate the benefit, and as long as it generates more value than we pay for it, we’ll purchase it.
I’ve rarely regretted buying any software to help my team and I, and even when it doesn’t work out, it’s usually tool specific, not use case specific. That means we cancel one tool to switch to another, similar one that’s better/faster/cheaper.
And all of this was learned before AI came along. Now, I’m rethinking this further, as now I realize tools like ChatGPT and Claude.ai can automate and speed up things I never thought software could.
The Bottom Line: Software helps you and your team go faster. Don’t slow yourself down by making it hard to add helpful tools to your stack, or being penny wise and pound foolish.
5) Marketing has to be a part of your plan from the start.
At the peak of the bottoms up SaaS era (which I consider roughly 2010-2020), it was often thought that building a great product that can expand virally in a company was the most important thing you could do. Some even thought of freemium as a form of marketing en lieu of other strategies.
While some of those rules still apply, it’s become clear that marketing must be a part of your plan from the start. Building software has gotten easier and faster, and AI is rapidly bringing commoditization to many markets, so you cannot ignore distribution.
Build it and they will come was never a particularly great strategy, but now it’s fatal. I think at this stage, teams should think in the frame of “Technical Cofounder” and “Distribution Cofounder”, because frankly, distribution is the most important thing a founder can work on if not building the product.
The good news is, all that effort investing in marketing early on can help you in a variety of ways:
Sourcing customer interviews: I used this blog to source the 40 managers I interviewed before we started building Lighthouse. If you can write a blog post, create an ad + landing page, or otherwise get attention for a problem, you can funnel that towards interviews and customers.
Easier trial and sales: Even if you have a great network, and you’re building in an industry you know, you’ll run out of friendly people to try your product pretty quickly. If you’re spinning up marketing efforts from the start, you can grow a lot faster.
See faster what you’re up against: Much like you don’t know if you have something until you charge money for it, you don’t know what marketing will work until you try it. Finding out your costs of acquiring a lead are much higher or lower than you expected can help you understand the viability of your business much faster.
Lay a foundation sooner: Especially if you want to try SEO or social media as a key tactic, it can take some time for it to start to pay off. That means the sooner you start, the better.
While I started thinking about marketing from the start of my last startup, I will be even more aggressive next time. Instead of blogging on my personal blog for the first few months, I would have started the company blog from the day we bought our domain. Every bit helps and gets you to escape velocity in your marketing faster.
The Bottom Line: Don’t wait to figure out marketing. You need to be thinking about it from the start to be sure you really have a good business that you are well positioned to grow.
6) Choose your industry wisely, and learn all about it.
Spotting a problem or an opportunity to make things better is a great way to come up with startup ideas, but it’s not all it takes to be sure you’re onto something special.
It’s really important to think through the business you’ll be building and the industry you’d be working in. They all have their flaws, challenges, frustrations, and benefits. Make sure they’re things you’re well suited to tackle, and would enjoy tackling.
A few examples of pitfalls that I’ve seen stop founders in their tracks:
Two introverted engineers start a company that turns out to sell best at trade shows. It was not a good fit and exhausted them quickly.
A product minded founder built an easy to use product, but couldn’t find a way to reach his target market consistently, because they rarely were by a computer.
Two founders who loved helping their end user found they couldn’t stand dealing with the buyer for larger deals, who had different goals and incentives.
Founders looking to pivot their business thought they had a great idea for a different department, only to discover that department had no budget for what they could do.
The point isn’t that you need to find the perfect market; that doesn’t exist, because they all have their flaws and challenges. However, you can save yourself a lot of frustration and heartache if you do your homework up front to understand your market more clearly.
When evaluating an industry or market, be sure to find out:
Who is your end user?
Who is your buyer? How do they like to be marketed to and what is their purchasing process like?
What features are absolute deal-breakers for them, or the most important ones for their current solution?
What do the largest companies in your industry do best? What did they get really right?
I know it’s easy to think that your one insight will carry you to winning the market, but that’s typically only part of a bigger picture. Taking the time to get to know your industry can help you place much smarter bets early on, and make sure it’s a mission you want to be on for the next 5-10 years.
The Bottom Line: Do your homework thoroughly to really understand your industry. Read public company quarterly filings, interview people all through the value chain, and look at companies that have succeeded and failed in the market to truly learn.
7) Raise your Hierarchy of Value and avoid “nice to have”
Other than not charging money soon enough, the number one mistake I see founders make is starting a business that’s actually a “nice to have.” In fact, those two mistakes tend to go hand-in-hand.
There are a lot of things people will use for free that they will *never* pay for. Unfortunately, this is particularly true in the world of SaaS. But is it really SaaS if people don’t subscribe?
As I’ve seen many startups come and go, rise or fall, exit or shut down, it’s led to a theory on how to evaluate the value of a startup:
The point is, you have to think about the value you’re providing from the start of your company.
The clearer, and more important, the value you provide, the stronger your business is. If it’s only nice to have, or it’s a very vague time or money savings, then you’re likely to have a hard time (hence the grim reapers in the image).
However, all is no lost. Often you can raise your value over time, jumping or expanding from problem to another. In particular, I’ve seen this in HR tech, where a small tool grows into a full suite for performance management (most companies feel they need annual reviews), and then ultimately adding payroll (a legally obligated action) to rise all the way to the top of the hierarchy.
Of all the lessons I’ve learned in SaaS, this was one of the hardest for me to learn. It essentially comes down to these fundamental truths:
Just because you solve a problem for an end user, doesn’t mean a buyer cares.
If you don’t give the buyer what they need, it often won’t matter how much the end user likes what you do.
The bigger the buyer, the further distance they typically are from end users. They may not even speak with them at all.
Until you understand both the buyer and the end user, you don’t know what your business’s potential really is. Especially as the bottoms up SaaS era winds down, you can’t shortchange what buyers are thinking. When budgets are tight, markets consolidate, and IT re-asserts they role in decision making, you can’t count on front line users of your product to get the deal done for you.
Beware startup siren songs…
Who is your buyer? How far are they from the end user?
These are the two most important questions you need to ask when starting to evaluate a SaaS business.
That’s because the farther removed they are from your end user, the more likely you’re at risk of a Siren Song; in cases where there is a large gap between buyer and end user, the end user likely has a terrible experience and is not consulted at all in the buying process.
That’s a dangerous temptation for founders, who see the end user experience and then think that’s a great startup opportunity.
A great example of this is the performance management space. That’s because:
HR is the buyer
Managers and Employees are the end users
HR doesn’t consult with managers and employees when choosing their performance management software
Most performance management software is painful for employees to use, especially at large companies (just ask anyone who has ever used WorkDay or Ultimate Software…)
When I started Lighthouse, I was so singularly focused on the end user (managers, in our case) that I didn’t even think about the buyer. That lead to some painful and challenging lessons as I found our product was ill equipped for what the buyers (HR) really wanted.
And it’s not just about the features you have, or are missing. It’s also the structure of your organization, the buying process, and your positioning.
What resonates with your end user, and how you acquire them, can be totally different than what your buyer wants. If you’re not careful, you can have your entire company structured in a way that is counterproductive to your long term growth goals.
That’s why this is one of the most important lessons to keep in mind from the start.
The Bottom Line: Learn who your buyer is, why they buy, what their process is, and the features that matter to them as early as possible. You may be surprised to then realize that the incentives the buyer creates are why the end user experience looks like it’s so appealing to start a company to solve (but will ultimately limit your potential unless you satisfy the buyer, too).
9) Customer service is every startup’s greatest advantage.
Have you ever used enterprise software and sent in a support ticket? Often, it will take days to get a response, and at best you get a work around, but never an actual fix of the problem.
For many people, they deal with these kinds of problems and response on a daily basis.
That means that when they try a startup’s tool, and they see the startup actually listens, and actually fixes the problem, or later adds the feature they requested, they’re overjoyed. Because of this, they often become incredibly passionate and loyal to the startup, even if it’s missing some features or has a few wars.
Roll out the red carpet and fix mistakes fast.
It never gets old seeing customers respond positively to startups showing them care and attention. Customer service is a huge asset for startups, whether founders directly talking to customers, a highly responsive customer success team, or engineers that take pride in fixing bugs.
One of the best things you can do in your early days is to lean into this advantage. The bar may be low to be better than your average enterprise tool, but you have an opportunity here to really wow your customers.
To do this, all you have to do is:
Involve your team so they see and fix bugs: Make sure your engineers especially are aware of customer feedback. Let them see the customer’s own words. “A player” engineers take pride in their work and love telling customers they saved the day and fixed or built the thing that was important to the customer.
Make it easy for people to contact you: One of the dumbest things I see startups screw up is making it hard to contact them. Make it easy! Whether you use Intercom, or another tool, the easier you make it for them to contact you, the more valuable feedback and positive interactions you can have with them.
Follow up and show you care: A lot of times, people just want to feel heard. It’s amazing how often even just asking a few questions to understand their request will make them feel special. Of course, if you then build the thing they asked for and follow up even a few months later, they’ll *love* you.
Best of all, doing this helps keep churn low and can cover for many limitations in your product. People love rooting for an underdog story, especially when, like a training montage, they see you continually getting better.
The Bottom Line: Customer Service is a huge opportunity for every startup to stand out. Lean into it and you can really build some amazing affinity for your product.
10) Set up analytics as soon as you launch. It only gets harder later.
When I ran product at KISSmetrics, I saw this problem all too often. Companies wanted to measure their product usage and run experiments, but they kept putting off starting. Then, by the time they realized they *must* set it up, it became a really big project.
At that point, they now had to think about either devoting a whole sprint to tracking everything in their product, losing a sprint of feature building or tech debt work. That’s a tough tradeoff to make when trying to hit key growth milestones, which often led to even more procrastination.
That’s why the best thing you can do is start tracking from the very first feature you launch.
In doing so, you can make it second nature to add a few events and properties to track every time you launch something. It’s very easy for engineers to add them while they’re already in that part of your code base, and you can make it routine to do so if it’s part of how you write out your product specs (as I describe here).
Bonus points: Build the habit of reviewing key metrics every week.
It’s amazing the difference a single email can make. While it’s great to be able to log into MixPanel, Amplitude, or another analytics tool to quickly look up a key number or funnel, it’s even better to have numbers you and your team can’t miss on a weekly basis.
That’s why one of the most useful things we did at Lighthouse was start having my virtual assistant go to a few sources to report 4-5 key metrics each week in an email to us. Here’s a snippet of part of it monitoring some of our key marketing metrics:
Thanks to this email, every Monday morning we knew if last week was better or worse than expected, how it compared to the previous year, and if there was an anomaly to investigate.
I’ve lost count of how many times we caught an issue we would have otherwise missed for weeks, as well as the many times we found something to celebrate.
The Bottom Line: Make measurement and looking at your data a central part of your startup from day 1. It will pay dividends for the rest of your startup’s life, and save you playing painful catchup later.
These are 10 lessons I’ve learned over the years that I keep in mind every time I work with a new client, and will remember when I start another company in the future.
What are the hardest or most important lessons you’ve learned?Share your advice in the comments.
Have you ever thought about building a free tool for your company? Do you want to build more buzz, get a ton more inbound SEO links, or drive signups and leads for your core business?
Or maybe you are a free tool skeptic, worried it will distract your team, take to much time, or not pay off?
I’ve always been curious about free tools, but haven’t been directly involved in many myself. So when I met Michael Novotny, who has become an expert in creating free tools, I knew I had to have him on the Practical Product podcast.
Michael is a product manager turned founder, who has helped build and launch dozens of free tools / side products now and studied hundreds of others with his company, Product and Build Co.
In this episode we go deep on this topic covering everything including keys to success, pitfalls to avoid, tons of examples, and how to convince yourself or your boss to take a shot at making some free tools or side products.
How to Use Free Tools & Side Products to Grow Your Business
Today we talked about how building free tools (aka – side projects) for your company can help drive major growth for your company.
Building these tools helps you a few ways:
People who use your free tool may directly sign up for your paid product when they see you made the free tool.
People using your free tool may give you their email address, which you can market to later.
Others will link to your free tool, boosting your SEO through improved backlinks.
Michael shares a lot wisdom and experience doing these, and the most important tips are:
Build a portfolio: You need to launch many tools (ideally 4-5 or more) so that some will hit, and others won’t. If you only launch one, the odds work against you on the moon and stars aligning for you.
Build in public/test with your community: To increase your success rate, validate and test the ideas you have for tools to see if they resonate and what are the most important things it needs to do to provide value.
Use low and no-code tools: You can build and launch a lot faster using these tools, and since it doesn’t touch your core product, it doesn’t need the perfect architecture.
There’s a lot more to this episode, so I encourage you to give it a listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
(2:04) – How Michael discovered the power of free tools to drive sign-ups for another product
(11:46) – What are a couple of your favorite examples of these tools?
(16:31) – Cases where free tools didn’t work out.
(21:55) – Are there businesses that shouldn’t be creating free tools?
(29:05) – What is Michael’s Side-Product Framework?
(34:56) – How should PM’s think about budgeting for Side-Products?
(42:08) – How do you come up with good ideas?
(47:55) – How can you start to validate some ideas for tools to see if you’re on the right track?
(54:09) – What should people do to make these free tools successful?
(58:05) – What are the best ways to tie a free tool to your product?
(1:03:32) – How much ongoing maintenance should you expect?
(1:09:18) – What are your favorite tools that help you piece this process together?
(1:13:58) – Keys to convincing your boss or peers to try free tools.
What does your sales team think of you? Does customer success enjoy their conversations with you? Or do you feel animosity and tension with them?
And what about with customers?
How about the squeaky wheel who sends in feature requests regularly, or the enterprise customer with contractual promises?
Product management is about relationships.
One of the biggest mistakes I see otherwise good product managers make is not managing internal and external stakeholders well.
Rather than building collaborative relationships, where everyone feels like they’re on the same team heading in the same direction, they sow seeds of tension.
As a product manager, any communication issues fall on you. It’s your job to build bridges, even on challenging terrain.
You can do that through a variety of tactics:
Product advisory boards, and regular check ins with key customers.
Peer 1 on 1s with key sales, customer success, account management, and other department leaders.
Regular updates, training, and collaboration on collateral creation for new and updated features.
Throughout those conversations, both internally and externally, there are two words to always remember: “Not yet.”
Let’s dive into the nuance of how 4 letters can make such a big difference…
“Not Yet”: The Two Most Important Words for Product Managers to Use
Remember when you were a little kid and you wanted something and you asked your mom or dad? How did you feel when they said “no”?
Chances are you were pretty unhappy.
We’re not so different when we grow up.
Just say no…to saying, “No.”
As a product manager, when you tell customers and colleagues, “no”, it creates problems for you now and in the future.
No is denying what they want.
No makes them feel unheard.
No is a wall between you and them.
And most importantly, no is the end of a conversation.
Where do you go after you say, “no, we’re not doing that”? You can possibly explain why, but the other person is likely already thinking about how they can either convince you to change your mind or tuning you out in frustration.
The Power of “Not Yet”
Four letters. That’s all that separates “No” and “Not yet”, but in reality it makes all the difference.
Not yet is, “we might do that down the line…”
Not yet is, “I hear you, but…”
Not yet is hope.
And most importantly, not yet is the start of a conversation.
“Not yet” builds empathy
If you’ve ever learned about the power of using “and” instead of “but” in conversation, you know that a simple change in word choice actually leads to a larger transformation.
By changing the word you use, you change the entire nature of your discussion the rest of the way.
When you say, “not yet,” it lends itself to explaining why. This is powerful because it helps them understand the choices you’ve made.
When it’s an internal stakeholder, explaining why can help them see the other priorities. I’ve lost count of the number of times that once I’ve explained what we’re doing right now already they suddenly are willing to wait on their request; you may even be working on something important to them.
Meanwhile, with customers, it’s an opportunity to build excitement and engagement. Maybe you can’t give them what they asked for right away, but you can tell them about some other things in the pipeline.
Often, a couple of the things you’re doing are also important to the customer. You can then offer them the opportunity to provide feedback on the feature as it’s developing, or early access. Either way, it ends up feeling like they’re coming away with something, even if it’s not what they originally asked.
Show your work.
A key part of all of this is that you’re showing your work to others. You don’t need to explain the whole roadmap, but even a small snippet can help people see there’s a solid foundation to the decisions you’ve made. It also demonstrates the hard work and rigor of the product team:
Data driven: Good PMs know their numbers, so you can explain to them how the feature they asked for may have a much smaller impact than the current features you’re working on.
Customer focused: Whether you have an enterprise contract with deadlines due in 30 days, or are finally delivering on the #1 most requested feature, showing that what you’re doing is backed by real customer insights shows you’re a PM that listens to customers.
Strategic: Great PMs see the big picture, and help others see it, too. Concisely explaining strategy comes with practice, so use these “not yet” conversations to practice clearly explaining how the new API opens up thousands of leads a month, or how the onboarding improvements will drive more revenue to hit key company goals.
When you show some of your cards to your colleagues and customers, you help them understand your decision making process. While they may not always agree, they’ll often respect the decisions you’ve made a lot more than when all they heard was, “No.”
In my experience, when you show you have data, strategy, and customer insights backing up your decisions and bets, your colleagues and customers will trust you. Just like they expect you to trust them to do their jobs well, they’ll see plenty of evidence to believe in you as well.
Save your relationships!
This may seem like a small thing, but I can tell you from experience, it matters a lot. No may feel like the expedient way to handle requests, but it comes with a long term cost.
Over time, saying “no” leads to resentment and may sour relationships. People you want to partner with to make launches successful and for everyone to hit their numbers suddenly avoid you, except when they want to demand and override your No’s. They may even try to go around you and talk straight to a designer or engineer to get what they want.
And since you represent the product team, it can even lead to inter-departmental drama and rivalries. Rather than engineering and sales being partners, they become enemies, with each side criticizing the other. I’ve seen and heard it too many times, and it’s really the fault of product managers on those teams for it becoming like that.
You can avoid being that kind of cautionary tale by taking the time to regularly communicate with other teams, stakeholders, and key customers. When you meet and talk with them, remember to use “not yet” so those relationships flourish and they understand your decisions.
Never underestimate the power of using the right words.
If you’ve been a first product manager (PM) at a company before you know what this means. For the rest, let’s take a look.
What is a first PM?
The first product manager (PM) is exactly what it sounds like: it’s the first product manager hired at a company.
Typically, that means you’re taking over for one of the founders who is now too busy to handle the responsibilities.
In other cases, the company has not really had anyone serve as product manager, and finally hits a point where they recognize the team needs stronger product direction and focus than a variety of people can figure out ad hoc.
In both cases, that usually happens somewhere between employee #8 and 20. So the team is small enough to be nimble, but big enough to make some serious progress.
So what’s a *second* first PM?
Joining a company as first PM is a big risk. The company usually has some traction, but not a lot. They’ve likely raised some money (or have substantial revenue), but not tens of millions in the bank.
However, that’s not the greatest risk.
The greatest risk is that the founders that hired you don’t know what they really need.
Unfortunately, the first first PM often ends up being a sacrificial lamb so that the company can figure out what they really need in product leadership.
Today, we take a look at why it happens, and what product people considering being a first PM should think about before taking such a role.
The Unique Challenges of the 1st PM
The first PM is a special job. You’re coming in to bring order to chaos, and disciplined habits to a company with some (or a lot of) traction.
With that comes a lot of challenges starting on Day 1:
1) Metrics: You may or may not have *any* metrics, which makes decision making looking back hard. If there are some analytics implemented, you’ll likely be the first person to seriously look at them regularly and use them to make product decisions.
2) Resources: The team may or may not be fully staffed. Chances are you’ll be working with a mix of junior hustlers who were early and are “figuring it out as they go” and the first executives brought in to bring order and scale. In particular, you may not have a full time designer to work with.
3) Process: Unfortunately, what worked in the “Figure it out” mode of early days, doesn’t work so well with a dozen engineers and a growing roadmap. You have to work hard to get buy in so that a little process can help everyone’s work go more smoothly. Sometimes, founders can be the most resistant to this.
4) Founder Passion: Giving up their baby to let you run product can be really hard. A founder’s vision & gut for what is “right” has gotten them incredibly far, and now you need to work with them to chart the right course forward. There’s a fine line between executing their vision, and being stuck forced to build things they want that you know aren’t the most important thing.
5) Founder experience: If they’ve never worked with a PM before, they may not know what that really means. Given how vague product responsibilities and outputs often are, it’s not uncommon to hear “I like how this project/new feature is going, but I have no idea how you’re contributing to that.”
Now, these challenges make the job uniquely difficult, but also can generally can be overcome as long as you don’t face too many of the above issues together.
Unfortunately, it’s their combination with the 2 biggest factors below that leads to a first PM’s departure, and a second 1st PM being hired.
Why the *first* 1st PM often ultimately fails
Most 1st PMs are experienced product leaders. Whether they’ve been a product manager for years, or started their own companies, they’re generally very T-shaped employees that know how to deal with a variety of challenges.
Despite this, being the first 1st PM still does not work out in a lot of cases. I’ve seen this firsthand and commiserated with fellow PMs who have been through it.
So what are they unable to overcome? Why do they ultimately fail?
1) The founders don’t know what they really want and need
The earlier a startup is, the more haphazard the hiring process is. At 10-20 employees, they often don’t have a recruiter (or often any HR) on staff, so they’re making it up as they go as they hire people. This means many hires are directly from their network or referrals from there, without a lot of vetting.
With all the problems that have built up leading them to realize it’s finally time to hire a product manager, they start asking around for product people they know.
Eventually, someone gets introduced to them that understands this early stage startup world. In the interview they’ll be able to point out some obvious problems the product or product team has with plausible solutions.
This makes the founder think, “Yes. I need this person to solve these problems!”
Unfortunately, when they hire this person, they later realize that while those problems did need fixed, they weren’t *the most important thing* they needed in a PM.
Instead, these founders slowly discover that the skills of the PM they hired don’t align as well as they hoped:
Market: Are they well-suited for the nature of your market? Do they relate well to your target customer?
Stage: Are they comfortable with where your business is in finding product/market fit? Pre-P/M fit requires a level of experimentation and exploration some PMs can be very uncomfortable with, and is very different work than post P/M fit.
Non-Technical: Is it a very technical product? Then your UX issues may seem glaring now, but won’t matter when you’re trying to make core feature innovations quickly.
Too-Technical: Is technology not the most important differentiator in your market? Then, a technical PM may relate well to a technical founder, but not bring the customer empathy or design skills that are more important in your market.
Rapport: The PM and the founder they report to have to build a very close relationship. If they think too differently, or clash in personality, it won’t work.
Culture: How the company operates often follows the habits of the founders. If they’re disorganized it can be very hard for a process-driven PM to bring in process and get buy in from colleagues if the founder isn’t supportive of those changes.
Hiring a first PM is like the story of Goldilocks; you have to try a few to find the one that’s “just right.”
Unfortunately, first PMs often end up being like Goldilocks’s first bowl of porridge; not quite right.
Given product management comes in many different flavors, it’s easy for founders to choose the wrong one for any of the above reasons, or similar ones.
The other side of the coin is that this is still an early stage company. Even if at the time you hired them, the PM is the exact right fit technically, market-wise, and culturally, it still may not work.
Why? Because if your company makes a major change, so does the PM you need:
B2B vs. B2C: If you take the leap from consumer to being a B2B product, there’s a good chance that your first PM won’t be the right fit on the other side.
Moving Up or Down Market: Someone great at building for the enterprise with many stakeholders and permissions leveling may not be good at building for SMBs who are used to free trials, and a self-serve approach.
Solution format: If you were a consulting and services heavy business it’s great if they’re from that world as well, right until you want to build a product that stands on its own without any of that.
Industry passion: Just because the PM was excited by your original mission and industry does not mean they’ll still be in love with your business if you suddenly have a whole new customer base to work with that’s very different.
On top of all this, as other roles are hired, what the PM needs to do could change, too. For example, if you hire an amazing designer who loves usability research, then a PM strong in that is less important than another unfilled gap.
One person’s trash is another person’s treasure.
Due to all these factors we’ve explored, the first PM ends up being a very expensive learning experience for both the PM and the company.
The company learns all the things they really need in a PM, and the things they really don’t. They can now confidently write a much more specific job description, and will be more precise in how they source, filter, and evaluate candidates.
Meanwhile, the first PM is likely feeling pretty burned out and frustrated. They fought many unwinnable battles, and in the end saw that they were never in a position to succeed. They may have even raised concerns during the interview about issues that ended up being foreshadowing of exactly what would go wrong.
This first PM has a short, challenging stint at a company on their resume, and leaves either saying “What if?” or “Glad I’m outta there.”
The second first PM then reaps all the benefits.
The glory of being the *second* 1st PM
Being the second 1st PM has all the benefits of being the first PM, but few of the drawbacks.
There are many reasons it’s fun and tempting to be that first PM:
Prestige: It’s really cool to be the first product person in the door. You call many of the shots, you get to bring in process *your way*, and put your stamp on a product with some momentum.
Equity: A good first PM can get a sizeable stock grant (0.2 – 1.0%) depending on pedigree and need, so the upside can be high.
Challenge: If you like rolling up your sleeves and making something from (almost) nothing, this is an amazing role, with other awesome, hungry, hard working people to go with it.
Growth: If the company succeeds and grows (which you play a key role in), you get to build a product organization, growing into a management track.
And unlike the *first* 1st PM, you are being hired with a much clearer picture of what they need; they’ll have learned from their mistakes the first time around.
This is why being the second 1st PM is one of the rare times it’s *not* a red flag that you’re applying for a role that is being back-filled.
In fact, it’s better than hearing it’s a brand new role, because you get some extra things that were created thanks to the efforts of the now departed first first PM:
Buy in: After what the other PM started, there is more support by the whole team and especially founders to make changes. They likely hired you specifically for skills and changes they now know they need.
Momentum: Chances are the first PM laid a foundation that gives the second 1st PM things to work with; they’ll have some analytics tracking set up, some semblance of project management, etc so you have the basic tools you need to do your job from Day 1.
Potential: The company is now a bit further along, a bit more traction, a few more key hires. So while you get the title, equity, responsibility, and opportunity, there’s a bit more certainty in the business so you can be confident in the opportunity.
I was a second 1st PM.
I’ve had a few friends go through being the first 1st PM and run into the challenges outlined, and once I heard their stories, I realized how much I benefited in being the *second* 1st PM at KISSmetrics:
Foundation: The first 1st PM had gotten us started on a number of key things I could pick up with: processes, customer lists, habits, etc.
Buy in: The team was experiencing a bunch of challenges as the 1st PM had left a few months earlier. They knew exactly what they needed this time, and were supportive of what I wanted to do from Day 1.
Opportunity: An amazing VP Sales had just come on, the business had hundreds of paying customers, Series A was raised, and it was clear what they needed and that I could run with it. I couldn’t ask for more.
At the time, I didn’t appreciate the battles that had already been won, and the buy in that I inherited. Now, I do.
To all the first 1st PMs, who often don’t vest any equity, and found a huge difference between promises during recruiting versus reality, we salute you. It’s not a job for the faint of heart, but there’s another PM who greatly benefited from your hard work.
What if I’m interviewing to be a first PM?
If you’re interviewing at a company that is hiring their first product manager, be sure to ask if they’ve already had a 1st PM before.
Their answer will be very revealing, and helps dictate what you do next…
If you’re the second 1st PM…
Dig into what the founders learned from the first PM. Find out why they think the other PM didn’t work out.
Look for signs that what they need is what you can do, and that they’re accountable to their side of what went wrong (or you may be set up to fail, too). The more thoughtful and introspective they are, and the more what they describe are things that you’re great at, the better your chance of success.
You also likely would benefit from networking your way to that first 1st PM. They likely know the skeletons in the closet and can give you an alternate perspective on the company. Then, you can work to discern the truth that is somewhere between what they and the founders tell you.
Not all previous PMs will want to talk, so if they decline speaking with you, respect their privacy. Instead, look for other ways to learn about the company like Glassdoor, asking others you may know there, etc.
Meanwhile, if you’re the first 1st PM…
Go in with eyes wide open. Proceed with caution!
Unfortunately, no matter your optimism, or pre-existing relationship, there is a high chance you won’t work out. Make sure it’s the right time in your career for the risk, you’re confident in the founder you’ll report to, and you can work from day 1 to iterate to what they need.
Once you’re there (or if you’re already the first 1st PM) a few things that can help:
1) Understand why you’re there
One of the biggest challenges of the 1st PM is turning a vaguely defined role and need into a clear cut set of goals you can achieve. Spending time with the founders to clarify everything can help you start on the right foot.
How to do it: Take another look at the job description and what you learned while interviewing. Talk with the founders to confirm what they need most, then deliver on those things as best you can.
2) Over-communicate
Building trust and confidence with the founder you report to is essential. You need to calibrate with them so they understand what you do and why, while also understanding their vision and expectations.
How to do it: Use 1 on 1s, weekly emails, get their feedback pre-launch, and give them access to the tools you use so they can see what’s happening.
3) Create a clear plan
Make a 30-60-90 day plan of what you are going to do, why you chose those things, and mutually agreed upon success metrics. This helps them understand how you think, and make sure you’re heading in a direction they agree with.
How to do it: A Google doc with bullet points is often all you need, and allows them to comment and ask questions easily. Then keep updating and reviewing it as you pass those monthly milestones. Quarterly product plans thereafter can work well, too.
There are definitely times where the 1st PM has worked out the first time, so it is possible. However, whatever vetting you typically do for a role, triple it before taking such a role, or even consider consulting as a way to try before you buy if you’re unsure.
Is a 1st PM role right for you?
Being a first PM can be a great way to learn quickly, level up your career, and work with amazing people. It can also turn into a short stint on your resume, cause burnout, and create deep feelings of frustration over what could have been.
If you’re thinking about becoming a first PM, realize it’s very different than just about any other product role you can have. Take your time, talk to others who have been 1st PMs, and make sure it’s what you really want.
There’s much more to the story…
There’s been a lot of interest in the life and challenges of 1st PMs, so to further understand this topic, we have 2 interviews on the Practical Product podcast to help you;
1) Hostos Monegro with the perspective of a 4-time 1st PM (Full show notes here)
2) Pulkit Agrawal with the perspective of a very candid CEO who had a 1st PM not work out (Full show notes here)
What’s Your Story?
Have you been a first PM? Please share your story in the comments, so others can learn from your experience.
>>> Are you looking for help hiring your 1st (or 2nd) PM? Would you like help getting your product processes in order?
>>> Or are you a 1st PM who wants help navigating these unique career challenges?
Contact me and I can help you: jason at be customer driven dot com or schedule a call here.
There are many skills that go into being a great product manager, and one of the most underrated is communication, as these Silicon Valley product leaders emphasize:
“As a product manager, it is imperative that you understand the company’s overall goals and objectives and exactly how your team fits in to the broader vision.“ – Josh Elman
“We lead by example. We succeed by making others successful. We listen first and make certain that others feel that they’ve been heard. We pursue diverse opinions. We rally our teams behind a vision that yields passion and commitment. We value and foster strong team relationships.” – Satya Patel
“Good product managers communicate crisply to engineering in writing as well as verbally. Good product managers don’t give direction informally. Good product managers gather information informally.” – Ben Horowitz
You can be the best former engineer or designer, but if you can’t communicate, not only with your product team, but the broader company, you’ll struggle.
Great Product Managers communicate beyond their teams.
While it’s important to develop great written communication skills, informal, verbal communication skills are just as valuable.
When you are working with other departments to either gather customer insights or share with them a new feature launch, you’re exercising crucial communication skills.
Now, you could just blast off an email, internal survey, or update a wiki page and consider your work done. However, you’re missing out on crucial relationship building and major learning opportunities. Every moment of contact with another team in your company is a leadership and learning opportunity for product managers.
The Secret, Winning Habit of Great PMs
When you’re a product manager you have to influence people, because you have limited power on your own. You need to get buy in to accomplish anything.
And to be a product manager people enjoy working with instead of loathe, you want to be a trusted, respected colleague, not a politician or Machiavellian monster.
And the best way to build that trust and respect? Peer 1 on 1s.
What’s a Peer 1 on 1?
Peer 1 on 1s are a secret weapon for many great companies. They help fellow managers commiserate and support one another, and teams that interact regularly work together better. Usually, these meetings happen every 4-12 weeks, depending on what the two people involved feel is the best frequency.
As a product manager, having semi-regular check-ins with key members of teams you work or interact with can be priceless. It gives you a chance to give and receive feedback, hear new perspectives, gather customer data from new sources, answer product questions, and build rapport with them.
It can also ensure that people understand how you approach product decisions. You may be crushing it as a PM, but that doesn’t mean everyone else sees it that way. Product people have some of the greatest visibility across an organization, which can make it easy to forget that not everyone knows everything you do.
Who should product managers have peer 1 on 1s with?
The culture of your company and the nature of your product can make this vary, so use your best judgment when you apply this to your job. For me, I was leading product at a 20-30 person SaaS startup, and so I will share what I found worked there based on the advice I received.
1) Your Product Team
Your engineers have an entire engineering org that decides their compensation, job title, and work. All you can do is influence what is worked on next and collaborate with them on making the best (not just good enough) solution. The same goes for designers.
When your team is small, meeting once every month or two with everyone can help ensure you stay on the same page and fix problems. Identifying a bottleneck, something frustrating, or a blind spot can save your team hours, days, or even weeks of lost time from infighting, inefficiency, or poor decisions.
You may also find opportunities to help them understand how you make decisions. This can reduce resistance to changes you propose and open up constructive feedback to communicating with them and their colleagues.
Everyone?!? At first, yes.
When you’re small (7 or fewer designers + engineers), meeting with each person can ensure your processes are working well and ensure everyone feels heard.
As you grow, focusing on the team leads who you work with most can help you scale. They can be a voice for their team. Assuming the design and engineering team leads have one on ones with their teams, they can raise with you any concerns they hear from their teams. (Note: it can help to remind the lead in advance to ask their team before you meet.)
Peer one on ones are a great way to take the temperature of your product team. If when you meet with them, they clam up, refuse the meeting, or seem combative, that’s a major signal you have work to do to improve your teamwork.
Having a good relationship with the product teams you work with is table stakes as a Product Manager. Yet, many PMs mess this up. Good peer one on ones are a good option to improve the relationships no matter your situation with your team.
2) Customer Facing Departments
As a PM, one of your most important jobs is to understand your customer better than anyone. There are only so many hours in the day, so even if you’re awesome and talk to multiple customers every day, you should still look for ways to get additional perspectives. And the best place to get those are others at your company.
Ask yourself: who else regularly interacts with customers?
Customer Success / Support
Sales
Account management
In many orgs those three departments are off in a different area of the company reporting to a different C Level leader than you. They may literally be on a different floor or in an entirely different office. Because of this, it’s easy for sales and product to develop different cultures and even some animosity.
Break down the silos with communication.
Product managers are the perfect people to break down those barriers. You’re probably already working with them more than you realize.
Product people often get pulled into sales calls on the biggest deals, and help launch new features that success teams must document and support. They’re also driving the roadmap that ambitious sales people may use to excite prospects.
When I was running product at KISSmetrics I met with all those groups. And in each case I had two goals:
Find out any lessons I should take back to the product team about customers.
Answer their questions and concerns they have about product today and in the future.
So I set up regular peer 1 on 1s with people from sales, customers success, and account management.
Here’s some of the kinds of questions I’d ask to make the most of the meetings:
Customer Success / Support:
What are you sick of answering over and over for customers?
What bugs do you find you have to help users work around most often?
How can I make your life easier when we launch new features or make changes in the product?
These questions help improve our process around launching new features, updating FAQs, and identifying existing problems in the product we should fix. Few things make success team members stuck on the hamster wheel of never ending tickets feel better than having things that drive them crazy in the product fixed.
Sales:
What are common product-related issues that are causing us to lose deals?
What features get leads most excited about our product?
Are there any areas of the product that are unclear to you that I can help you understand better or fall flat in your demos?
These questions often required me to do a little 5 why’s to dig deeper to really understand and get them out of their sales mindset. Yet, with a little effort, I often found gold when I did. It also helped me better understand how my conversations with customers compared to those by sales. There’s a lot of great customer problem knowledge trapped in your head as a PM. Transferring it to sales team members can drive revenue for your company.
Account Management:
What features do you find you have to explain to customers the most? What’s most confusing?
Where in onboarding do users tend to get stuck most? How do you help them?
What could product do to make your job easier/better?
The people that help customers get activated will know many of the pain points that are affecting your onboarding funnel. Much like Customer Success team members, removing friction they deal with every day can really make their day, and help your customers.
Peer 1 on 1s are a privilege, not a right.
I worked hard to ask lots of questions and be helpful in these meetings. After the first meeting, I expected they would be prepared as well. I only continued meeting with people that truly brought good data, ideas, and/or concrete feedback. Otherwise the 30-60 minutes we would meet could be better spent elsewhere.
This was a challenge, especially in sales. Not all sales people really get to know their customers, but the best ones did. The best could coherently explain why we lost a deal versus just trying to ask me for every feature a competitor had.
The same was sometimes true in success; I didn’t want to know what happened that they remembered today. I wanted numbers so I knew how big a problem it was.
This then helped me make the business case when trying to decide between building something new we could sell and fixing what we had. When you can prove someone that costs $35 per hour is wasting 10 hours a week on something and it affects customers X, Y, and Z, it’s much easier to justify a change.
Build a Customer Driven Culture
When I set out to have these meetings, I was just trying to get more data and feedback to do my job as a PM better. A great byproduct of the meetings ended up being that everyone in the company became more customer driven.
As I met with people more regularly, and they saw me take action on their feedback, it created a positive feedback loop. The more I listened and demonstrated I heard them, the more they wanted to provide more valuable insights and contribute. That led to more discussions about approaches they could use in their job to get me better data and good questions to ask customers.
Patterns converge
What was particularly fascinating to me was that quite often, I would hear similar things from the majority of people I would talk to; often an issue in product would impact everyone in different ways, whether it made a sale harder, increased support tickets, or changed how account managers taught our product.
By empowering all of them to share with me what they were experiencing and teaching them how to best do so, they helped me better triangulate customer needs and calculate fully their impact. With everything else on everyone’s plates, this would never have happened without regularly scheduled meetings to talk about it.
—
There’s always more work to be done than time for a product manager. Taking the time to have peer 1 on 1s with key members of teams you work with can be an invaluable part of your processes as a product leader.
—
Want to work with a product person that lives this customer driven approach every day?
If you’re an engineer in San Francisco interested in joining a fast growing, early stage startup, I’d love to talk to you about how my startup, Lighthouse, can be a great opportunity for you. Send me an email at jason at getlighthouse dot com and tell me a bit about yourself.
