“An ounce of action is worth a ton of theory.” — Ralph Waldo Emerson
Today, you can listen to podcasts, watch videos, read blog posts, and have endless discussions on Linkedin and Twitter about AI.
But what really matters is what you put into action and how you actually use it to save you time, help you do things you couldn’t do before, or get better results.
From my observations, the delta between what is possible for PMs and what PMs are doing today is quite wide.
While AI trailblazers are going deep, building tools for themselves, making podcasts and courses to teach others, and creating new, innovative ways to do more, faster, most PMs are busy doing the work and many are falling behind.
Today’s post is to help you and any PMs on your team quickly and easily catch up to what is possible today with AI.
How to Use AI to be a Better PM Today.
While you don’t hear much about AI hallucinating anymore, the fear still exists. It’s easy to think that spending a lot of time using AI just leads to wasted cycles and questionable results.
Fortunately, each of these suggestions are battle tested and well within the capabilities of AI. And where there are potential issues, I’ll call them out so you can keep them in mind.
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.
If you’re a company that cares about listening to your customer, there’s a good chance you’ve at least thought about adding a feedback widget to your product.
You’ll notice they’re particularly common in LLM products like ChatGPT, Perplexity, and Claude, where they appear right below the AI’s response to your prompt with a simple thumbs up and thumbs down:
What are your customers thinking?
One of the great things about website feedback widgets is that they help you answer that all important question: What are my customers thinking when using my product?
While you can send surveys, schedule interviews for deep dives, or tell customers to email you, few things are as convenient for them as being able to send you feedback in the moment while using your product.
That’s why so many companies have decided to build their own feedback widgets to embed inside their products.
As I’ve been researching and building Product Arrow, I’ve seen dozens of widgets across the products I use regularly and new ones I’ve been trying. And in doing so, I’ve found a few widgets that stand out as particularly beautiful, clever, or helpful.
Today, I want to share those with you, so you can consider adding some of their style or functionality to your product, too.
One of the most common frustrations with AI is not getting what you wanted. For every time we get just what we wanted (or more), it seems like we also get a mess of nonsense or things we know are wrong.
And sometimes that happens, because the job is literally impossible for the AI.
Other times, we didn’t write a good enough prompt. Going back to the drawing board, providing some examples, and giving more detailed specifics can help get a better result the next time.
Yet, sometimes none of that is enough, even if it *should* be possible.
“The square root of slop is slop.”
Some friends and I were talking about the state of AI and noticing how you can get plausible sounding ideas and analysis, but when you dig in, you see it’s completely wrong.
Sometimes that’s hallucinated entries in a spreadsheet that doesn’t actually add up correctly, despite looking great. Other times, it’s customer feedback analysis of thousands of entries, with a beautiful report and quotes, where you can’t actually confirm the underlying sources that led to the ranking of problems it offered. Or, it’s simply a report or newsletter draft that starts out sounding good before drifting off to classic AI generated slop.
As my friend put it, “If AI is just math at scale, then scaling noise just gives you louder nonsense.” Or put more simply and more memorably, “the square root of slop is slop.”
If you’ve ever submitted product feedback through a customer support widget like Intercom or Zendesk, you know how much of a lost, black hole it can feel like.
Yet, for many companies, that’s exactly where product feedback goes, never to be seen or heard from again.
It’s not Customer Success’s fault.
Customer support and success have important jobs. They’re helping fix problems, educate customers, clear up confusion, and catch bugs.
But triaging problems and being patient with frustrated customers is a totally different skill set than understanding customer needs and making product decisions.
It’s no surprise then that the feedback CS does receive often gets lost in the shuffle, dumped in a backlog somewhere, or filed away, never to be seen again.
What else are they supposed to do?
Let’s take a closer look at these misaligned incentives and responsibilities, and why they leave customers feeling unheard and product teams missing out on priceless customer feedback and connections.
“If you love what you’re doing and you always put the customer first, success will be yours.” – Ray Kroc, co-founder of McDonalds
“The more you engage with customers, the clearer things become and the easier it is to determine what you should be doing.” — John Russell, Harley Davidson
“Make something people want.” – YC
There are a lot of catchy sayings and aphorisms about listening to your customers.
And they’re right. It is *really* important to listen to them.
Yet, in practice, there are a lot of reasons that doesn’t happen. Or at least not as well as you would ideally like to.
And the cost is high. Building what internal stakeholders, “visionary” founders, or selfish PMs want instead of what the market is signaling wastes time, capital, and precious opportunity.
In a world where AI is helping us all move much faster, and the cost of building is rapidly falling, building the right thing has never been more important; you’ll either get it right, or someone else in the market will.
Based on conversations with PMs I’ve coached, those I’ve recently interviewed for my new startup, and speaking with friends, here’s the common blockers (and sometimes excuses) for why the voice of the customer isn’t heard as clearly as it should at companies of all sizes.
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:
