Practical Product Ep 8: How to Write Product Specs Your Team & Executives Actually Want to Read

Are your product specs high quality? Do they succinctly and clearly convey what you’re working on, why you chose them, and what your engineering and design partners need to do their jobs well?

Or are they kind of random, with each one different than the last?

I’ve helped dozens of PMs improve their product specs, and I’ve been lucky to learn from one of the best how to make a great product spec. Which is why I knew I needed to do an episode on the subject to help everyone improve their product specs.

Today, we cover:

  • The most common mistakes PMs make in their product specs
  • How I learned the right way to make a spec
  • The key, fundamental concepts underlying good product specs
  • and most importantly: Exactly what goes into a great product spec (aka- Product Thesis)

How to Write Product Specs Your Team Actually Wants to Read (AKA – The Product Thesis)

Everyone writes product specs regularly in their job as a PM, but few do a great job with them. These poorly constructured specs then cause all kinds of problems on product teams including:

  • Engineers and designers confused and uninspired about what they’re making
  • Delays in shipping due to misunderstandings and miscommunication about priorities
  • Disappointed execs who don’t get what they expect

And a lot more. Yet, it keeps happening because PMs don’t realize that the root cause in their specs that:

  • Do not cover the right topics
  • Are wayyyyy too long, and filled with fluff
  • Tend to be overly prescriptive on the solution instead of collaborating with your team on it
  • Lack data to back up your decision
  • Fail to share an inspiring WHY to motivate your and convince your team
  • Are inconsistent spec to spec making it harder to read and digest

That’s why we need to hit the reset button and reshape how you make product specs with something called The Product Thesis. Listen in to learn more about it:

Highlights of the episode include discussing:

  • (0:49) – Mistakes made on the average Product Spec
  • (3:17) – Introducing you to The Product Thesis 
  • (10:06) – What goes into a Product Thesis?
  • (12:05) – Section 1: Why are we working on this next?
  • (14:57) – Section 2: When and how do people use this feature? (Aka – what are the use cases?)
  • (18:24) – Section 3: What problems do we need to solve, and in what priority?
  • (24:19) – Section 4: How much time is budgeted for this project? When does this need to be completed by?
  • (25:56) – Section 5: What are the future considerations that must be accounted for?
  • (27:28) – Section 6: What is our KPI or metric for this thesis?
  • (29:59) – Optional: For larger companies: Who are the stakeholders and how/when do they need to be involved?
  • (31:14) – Optional: What kind of launch or marketing/sales efforts go with this feature?
  • (32:27) – Section 8: Further Reading

Key Show Notes & Further Reading:

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here:

Practical Product Ep 7: How to Supercharge Growth with Free Tools & Side Products with Michael Novotny

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:

  1. People who use your free tool may directly sign up for your paid product when they see you made the free tool.
  2. People using your free tool may give you their email address, which you can market to later.
  3. 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.

Key Show Notes & Further Reading:

Case studies and examples of Free tools:

No Code and low code tools to help you build your free tools:

Connect with and learn more about Michael Novotny:

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here:

Practical Product Ep 6: Succeeding as a Remote Product Leader w/ Valentina Thörner, Product Advisory at Klaus

Were you ready to be a remote PM when COVID struck? Are you finding yourself still remote 2 years later?

Or maybe you’re back in the office, but your company embraced remote work, so some of your team is distributed elsewhere?

Regardless of your situation, if you or part of your team is not co-located with you right now, you have special challenges as a product manager. What works in office doesn’t always work remotely.

That’s why I knew we needed to bring in an expert to talk about remote product leadership during this season of Practical Product.

And Valentina brought the knowledge. She’s been leading remote teams for over a decade and teaching others with her courses and consulting for much of that time.

We had an amazing, 95-minute conversation covering a wide range of topics that any manager leading a fully or partially remote team needs to hear.

And if you’re thinking about changing jobs and joining a remote organization, you’ll want to listen in too, because we specifically talked about the transition you’ll have to make as well.

How to Succeed as a Remote Product Leader (even if you’re new to it)

Some jobs are not that different doing them remote versus in person. For example, a sales rep may have to sit and make the same calls, send the same emails, and generally have identical tasks that if anything, might be easier in a quiet environment remotely.

For a highly collaborative role like product management, that’s not the case. A LOT changes.

What works in person, doesn’t always work remotely, and often, the solutions aren’t even a 1 to 1 trade. Instead, you have to reinvent entire workflows and processes to fit the different way of working remotely.

Today’s discussion with Valentina Thörner goes deep on exactly these things.

You can listen on your favorite platform or in the player below:

Highlights of the episode include discussing:

A deep dive on remote vs. in person communication advice, and great team construction:

  • (1:43) – What are some of the biggest changes when someone shifts to a remote PM role?
  • (11:38) – How can a Remote PM be successful?
  • (14:55) – How can Remote PMs understand how their team is feeling and reacting to their work and communication in an asynchronous environment?
  • (24:00) – Do you think the ideal product team size is different for remote vs. in-person?
  • (26:54) – How do you avoid meeting & Zoom fatigue / overload?
  • (42:16) – How do you create the collaborative juices from a whiteboarding session for a remote team?
  • (48:48) – How often do Remote product teams need to be together in person?
  • (51:53) – How much would you think about geolocation when it comes to constructing pods?

If you’re thinking about working as a remote PM or want to find a great remote company:

  • (58:49) – What are ways PM’s can prepare themselves for the shift to a remote-first organization?
  • (1:04:54)- What questions would you recommend asking when sussing out if a remote company is the right fit?
  • (1:14:15) – What skills would you recommend developing for folks looking to become remote PM’s?
  • (1:20:32) – What are good ways for folks to build their writing and communication skills?
  • (1:27:10) – Are there any more skills people need to develop to be great Remote PM’s?

Key Show Notes & Further Reading:

– Books and other helpful links from today’s episode:

Many books and great blog posts were mentioned in this episode. Here’s a rundown of the books:

And blog posts for you to read:

Connect with and learn more about Valentina Thörner:

Want to be the first to hear about new episodes of the Practical Product podcast, and other blog posts I write about Product Management? Subscribe here:

Practical Product Ep 5: Why intellectuals are wrong about AI, the Bundling Phase & What it means for PMs, and more.

What are the consequences of AI making our lives easier and better? What jobs will be lost and what happens when they are gone? And how should product managers think about the new, bundling phase we’ve entered?

In this week’s episode of the Practical Product podcast, you’ll hear my thoughts, and some quotes from others related to a few key topics that have been top of mind lately:

  1. What it means to now be in a bundling phase for tech and how PMs should adjust their strategies.
  2. A problematic mindset I see and hear in too many PMs.
  3. The truth about AI and the future of work. Will we really see jobs disappear?

Practical Rants: Why intellectuals are wrong about AI, what PMs must do as we enter the Bundling Phase, and a key mindset PMs must avoid

This episode is a collection of my thoughts on some trending topics I am seeing in the world of tech and product management relevant to PMs:

1. We are in a Bundling Phase: How can we as Product Managers bundle our offerings for consumers who are concerned about economic instability? We need to establish our products as absolute must have’s in the eyes of our customers and recognize the new market dynamics to survive and thrive .

2. Let’s stop the Self-Deprecation in Product Managers: Don’t be the “this is fine” dog meme, be part of the solution when you see negative trends within the culture or product at your organization.

3. The Truth about AI & the Future of Work: I break down a clip from Yuval Noah Harai and his horrendous take on the “Useless Class” of folks he predicts will grow as technology continues to advance. We must shut push back on this rhetoric and build tools for an abundant AI future.

You can listen on your favorite platform or in the player below:

Highlights of the episode include discussing:

  • (1:27) – Bundling within companies amidst economic uncertainty
  • (6:34) – What to do as a PM when you see customer churn due to bundling
  • (10:23) – Understand your secret sauce
  • (12:37) – Self-Deprecation in Product Managers
  • (17:29) – Yuval Noah Harari on the “Useless Class” & The future of work with AI
  • (29:22) – Product Managers can be part of the solution
  • (32:04) – Final Thoughts & Recap

Key Show Notes & Further Reading:

1) Now entering the Bundling Phase…

I saw a tweet from my old boss and mentor, Hiten Shah, that really hit home:

That got me thinking…why now?

Now you have the combined argument of:

  1. We had too many tools to manage. IT hated this. It was a security and info management nightmare.
  2. Budget cuts. You’d rather cut a tool than an employee. And there’s an easy case to make to decision makers that, “hey, this big system does all these things. Let’s cancel all the other tools and consolidate on this.”

And for PMs, this means you need to consider a few key tactics to navigate this reality:

  • Look for breadth over depth in feature building. In a consolidation phase especially, you’ll be competing against a lengthy feature checklist, where one system that does everything gets the purchase, and there’s no second place. 
  • Take advantage of integrations and APIs. If you integrate with tools they use, it helps keep you sticky. And if you have an API and others build on top of what you’re doing that’s also a great, viable strategy to expand your functionality faster than your own team can build. 
  • Build for the right ecosystems. Microsoft and Salesforce are two of the biggest heavy hitters. They’re exactly what people are going to consolidate on because it’s so easy to. Be prepared for push back though…both are miserable to build on. 
  • Tighten your relationship with Sales and CS. You need to know how you’re winning and losing deals. Find out how account management is doing trying to retain key accounts and what they’re saying they’re thinking about. 
  • Understand your secret sauce and champions. What’s unique about your company? What do you do better than most? What critical thing do you deliver that will have someone with influence at a customer banging the table to keep you? If you don’t have it you better get it. If you do, make sure that feature stays great. Don’t let the goose that lays the golden eggs get hurt. 

2) The problem of self-deprecation for product managers.

While this meme can be funny, it shouldn’t be your main identity as a product manager:

It sends a bad message to everyone around you if you’re constantly self deprecating about your job:

  1. It makes you sound like a victim, and potentially setting you up to welcome more abuse
  2. It creates a self-fulfilling prophecy where you look for confirmation of this negative way of living as a product manager. Build for and focus on the positive direction.
  3. It sends a bad external message to other PMs that “this is the job.”

And maybe in some cases “this is the job” but ask yourself if that’s what you really want? 

3) Why AI is NOT going to cause massive unemployment.

Harari is a monster disguised as an intellectual.

The ignorance of Harari is staggering. He oversimplifies things and has such an out of touch view of reality.

These changes always happen. Every time there’s talk of this concern.

There used to be tons of jobs for horses before cars: Poop shovelers, veterinarians, horse feed, etc. 

And cars of course created jobs: car dealers, mechanics, all the many parts needing manufactured, car washes, windshield repair, gas stations and the entire oil industry, etc. 

There were floors and floors of accountants and bookkeepers, and then the spreadsheet came along…and with the rise of computers, I think we can all see the many jobs they created, and how information and services were democratized. 

There are plenty of jobs to fill

In today’s world, it’s crazy for someone to argue there are no jobs. There are tons of opportunity all around us:

  • We have organizations like Bloomtech happily training people, many coming from “low skill” jobs.
  • Most tech jobs are self taught, too! Can you major in sales or product management?
  • There are tons of labor jobs that no robot will take for some time, which as of now is estimated to be over 4 million jobs, and once again there are training jobs like Mike Rowe Works.

This means that even if some jobs are displaced by AI, there’s no reason to believe there won’t be work for these people.

AI makes jobs more efficient, not eliminated.

Not one reply to this great question about copywriting AI mentions *anyone* losing their jobs:

And similarly, Github’s AI is making engineers faster, not taking their jobs:

When you free up a worker’s time, they can do more and different things.

Product Managers can be part of the solution.

If you’re working on a product that uses AI, think about how you can help make a better future for workers:

  1. Build your tools to make their jobs faster and better, not replace them. You’ll get less adoption resistance and they’ll become your loyal fans.
  2. Make your interfaces more accessible and easy to use. This will allow newcomers to use your product, and speed up adoption.

Harari is a monster and a terrible human being.

Harari is an example of an intellectual monster. He is giving speeches like the video embedded above to world leaders at places like the World Economic Forum. He has a large platform and the ears of people that make his ideas very dangerous.

Did you know that part of Nazi eugenics called some people, “useless eaters”? To use phrases like the “Useless Class”, is the first step to genocide and should be condemned fully, especially in intellectual conversations as we all develop technology people will be using every day.

Do not fall for those false pity ideas from false intellectuals. There will always be jobs. And every new technology creates new jobs and opportunities as much as it may eliminate a few old ones.

We as product managers have the opportunity to be a part of the solution and create the future that helps everyone, and does not consider anyone “useless.

Want to be the first to hear about new episodes of the Practical Product podcast, and other blog posts I write about Product Management? Subscribe here:

Practical Product Ep 4: The Curse of the 1st PM – Part 2: The PM View with 4-time 1st PM, Hostos Monegro

Why is it such a struggle for 1st PM hires to succeed? What are the challenges from the perspective of a product leader who has done this before? How can you avoid being a casualty of the 1st PM curse?

Today, we answer those questions and a lot more.

A chance meeting…

Back in 2019, I was living in New York City. I was meeting other PMs in town, and by chance was connected to Hostos Monegro. As it turns out, we had a lot in common, as we’d both been a 1st PM multiple times at startups.

As the conversation continued, we realized there was *a lot* in common between our experiences. It helped me realize that the situations I experienced were possibly less about me, and more about the nature of the job. It ultimately led to the inspiration for the now oft-discussed post, “Why you want to be the second 1st PM.”

Knowing how much credit Hostos deserved for inspiring and helping craft the ideas of that post, I knew there was no one better to talk about the product manager perspective than him. When I started planning this podcast, he was one of the first people I asked to come on the show, and this week’s episode is the product of that discussion.

The Curse of the 1st PM – Part 2 w/ Hostos Monegro, 4-time 1st PM

If you haven’t read it yet, the best place to start is reading my 2019 post, “Why you want to be the Second 1st PM” to get context on this unique role that comes with special challenges, and sometimes a lot of baggage. You can also check out Part 1, with a CEO who hired (and fired) a 1st PM recently here.

Today’s discussion with Hostos dives into lessons learned on having made the majority of his career being either the 1st PM, or as our original post called it, the *second* 1st PM (who comes after the first one didn’t work out).

If you’ve ever thought you wanted to try being a 1st PM, or already are one, this is a great episode for you. We cover key topics like how to screen for the right founders to work with, why this role can be awesome and fulfilling, and how to avoid some of the common pitfalls that come with the curse of the 1st PM.

Highlights of the episode include discussing:

  • (2:14) – What is it like being a 1st PM the 4th time around?
  • (5:53) – How did you think about filtering the Founder when looking for a 1st PM role?
  • (9:14) – What are the awesome parts of this kind of role?
  • (15:07) – What are some of the hardest lessons you’ve learned as a 1st PM?
  • (25:17) – Advice for someone interested in taking on the 1st-PM role
  • (38:40) – What should potential PM’s look for in a company to determine if it’s a good fit?
  • (46:52) – Recommendations if you think some of these 1st PM pitfalls apply to your situation
  • (48:11) – Advice for founders thinking about hiring their First-PM
  • (54:00) – How the First-PM be set up for success

You can also learn more about Hostos or get in touch with him on Linkedin and Twitter.

Want to be the first to hear about new episodes of the Practical Product podcast, and other blog posts I write about Product Management? Subscribe here:

Practical Product Ep 3: The Curse of the 1st PM – Part 1: The Company View with Pulkit Agrawal of Chameleon

Why is it such a struggle for 1st PM hires to succeed? What are the challenges from the perspective of the CEO who hires them? What do founders learn in the experience when seemingly inevitably, the 1st PM they hired with the best of intentions didn’t work out?

Pulkit Agrawal mentioned me and my post on “Why you want to be the 2nd 1st PM” when he lived this challenge firsthand:

And knowing he had just gone through this, I knew we had to talk about it on the Practical Product podcast. That’s why this week’s episode is all about it.

The Curse of the 1st PM – Part 1 w/ Pulkit Agrawal, CEO of Chameleon

If you haven’t read it yet, the best place to start is reading my 2019 post, “Why you want to be the Second 1st PM” to get context on this unique role that comes with special challenges, and sometimes a lot of baggage.

Today’s discussion with Pulkit helps answer the question you may have from the post, “How does this happen?” Pulkit read my blog post, new the risks, and yet it still happened.

Are all 1st PMs doomed? Probably not, but the challenges and unique factors of being an early stage startup do make for an ever-changing set of circumstances that can make someone who was the right choice when hired no longer the right person 6-18 months later.

Pulkit and I have a really candid conversation about what happened, what he learned, and most importantly what he’ll do differently with the second 1st PM (who he just hired).

Highlights of the episode include discussing:

  • (5:35) – How has your approach changed for hiring PM #2?
  • (6:27) – What got you excited about the person you ultimately hired for the #1 role?
  • (13:52) – When did you start to realize things may not be working out?
  • (18:28) – How did you handle the transition of a PM leaving the team?
  • (25:13) – Is it inevitable that the first PM will never be a perfect fit?
  • (34:02) – How are you thinking about changing your hiring process the second time around?
  • (35:44) – What advice would you give a founder who’s considering hiring their first PM?
  • (43:17) – How can the founder set the PM up for success?
  • (45:03) – What advice would you have for PM’s interviewing for a first PM role?
  • (48:52) – What are some red flags candidates need to look out for?

You can also learn more about Pulkit’s company at Chameleon.io, and check out their blog to learn more product management and user onboarding tips.

Want to hear about every episode of the Practical Product podcast as soon as it drops, and other blog posts I write about Product Management? Subscribe here:

How to do a Jobs To Be Done Interview

Jobs To Be Done (#JTBD) is getting a lot of attention lately as a valuable, new method for product and marketing teams (if you’re not familiar check out the podcast and the Milkshake video that started it all).

For the product team, they can better understand the motivations and needs of their users. As a marketer, you can understand the journey a future customer goes through to go from considering finding a solution to their problems to actually choosing your product. This is priceless for your marketing site and copywriting as well.

There’s a lot of great posts coming out on why Jobs To Be Done matters, but I haven’t seen much on how to actually do the interviews. Since I’ve done them a bunch myself, taught a number of my friends, and written previously about how to do customer development interviews, I wanted to share the process I’ve learned and evolved:

How to do a Jobs To Be Done Interview

Getting in the right mindset

These interviews are very different than a traditional customer development interview, usability testing, and other common customer interview practices. It’s a lot more free form than other processes that usually just want to uncover a few problems or learn some basic customer demographics.

For JTBD, you need to think of yourself like a detective interviewing a witness at a crime scene, or a documentary filmmaker trying to tell a story. Believe it or not, there’s a significant process a user goes through to become a customer and it’s often measured in weeks or months. Once you finish this process you’ll be able to fill in a timeline that looks like this:

jtbd-timelineThe key is to get users thinking about their purchasing process and filling in the gaps while they remember the various events along the way. Your users won’t think of them with the words of that timeline, but you’ll see where those things happen.  Fortunately, the questions I’ll show you will help your interviewee remember the various steps.

Here’s a quick cheat sheet of the terms on the timeline with an example of a friend who bought a new car.  Skip down if you already understand the timeline.

1) First Thought: What caused the first thought to think about making the purchase? When was it?

– My friend owned a Prius and it was a few years old. One night when he was driving home from work, he hit a neighbor’s trash can that had rolled onto the road. He looked at the front of the car and saw it was kind of scuffed up, but not enough to take it to the shop. This made him think, “Maybe it’s time I got a new car.”

2) Passively Looking: What did they do while they were passively looking? For how long?

– My friend started thinking about what kind of car he would get next. He knew he wanted a fast car and was focused on luxury brands. He started browsing Audi, BMW and Lexus sites to look at their cars.

3) Event #1: What happened that switched them from passively to actively looking?

– My friend’s wife would need some convincing to agree to a new car. As it turns out, about a month after the trash can incident, her brother mentioned he needed a car. My friend could give his car to his brother in law and kill two birds with one stone.  With permission from his wife, he could now actively look for the car.

4) Actively Looking: What did they do while they were actively looking?

– My friend started looking up reviews of the various cars he was interested in and asked friends that owned the cars for their opinions. He has a long time mentor that he in particular appreciates their taste, and so he asked their opinion.  My friend is an Apple fanboy, so craftsmanship is really important to him as well. Both his mentor and his own research pointed to Audi being the brand best committed to those ideals.

5) Event #2: What was the event that made him decide to make a purchase at a specific day/time?

– My friend had two events that combined to push him to finally make the purchase. He was scheduled to have surgery soon and he wouldn’t be able to drive for awhile after surgery. Christmas was coming soon too.  He wanted to get the car before his surgery so he could enjoy it a bit first and not put off the purchase that much longer and knew he could claim it as a Christmas present to justify the purchase then. (Now those luxury ads about buying cars as gifts make more sense, right?)

6) Deciding: What helped him make the purchase?

– Now that my friend was ready to buy, he went to the dealerships and test drove the cars that were finalists (a BMW and an Audi). He had a great time speeding down the highway in the Audi, so combined with his friends recommendations and his own research, he was finally ready to buy the car.

Unfortunately, the answers don’t come out that cleanly. You will get bits and pieces of the various steps during the discussion, which is why these interviews have to be more exploratory. You should be able to assemble the timeline afterwards though and start to see how you can market to future customers like your interviewee and alter your product to better fit them (like helping them see the most important value sooner).

The Jobs To Be Done Interview Script

Ok. We’re finally here to the script. Remember, the goal of the conversation is to help the person you’re interviewing remember the steps and key moments in the process that led to the switch.

A few rules for the interviews:
  1. Find people who recently purchased. Most people won’t remember well anything more than 60 days ago. The more recently the event happened, the more likely they are to remember all the details you’ll hope to capture in the interview.
  2. Don’t interrogate. You want your conversation to feel like they’re just talking to a friend.
  3. Pauses are ok. The interviewee is likely going to have to think hard to remember details. Give them time and they’ll often remember things so don’t be afraid of 10-20 seconds or more of silence.
  4. Bounce around the topics. Being non-linear in your questions often leads to new discoveries. Circle back to different things you talked about throughout the interview.
  5. The best stuff comes around 20-25 minutes in. Keep digging and listen carefully. You’ll have a real *woah* moment right around then.  For above timeline example, my friend didn’t initially realize the trash cans started his car buying process.
  6. Take notes & record the interviews. There’s lots of gold in these interviews. You don’t want to forget anything, and be able to review and share them with others later.
  7. Work in teams. A pair often can do better at examining all areas of the moments you’re trying to understand and help with taking good notes. While one person is writing a key point, the other can be asking a question.
  8. Talk to more users until they all sound the same. It generally takes 7-10 interviews to get the patterns of everyone. I found out the root cause of churn for a company by interviewing a bunch of their recently canceled customers and it was very different than what people said it was in an exit survey.
  9. Organize your findings with the Timeline and Four Forces. That’s what they’re there for. You can learn about the Four Forces here.
  10. Don’t lead the interviewee. Try very hard not to ask Yes/No questions. Instead leave room for explanation and listen. Ask lots of “why” and “tell me more” questions.
  11. Timing Matters. Try to find out the day/week/month/hour something happened. There’s often patterns to be found in that timing and it can also help them recall other details as they concentrate to remember.
Jobs To Be Done Questions to Ask:

Unlike other kinds of interviews, you don’t need to always ask every question in the exact same order. These are all just ways to explore the process of their purchase and help them remember their story.

  • When did you first start thinking about your purchase?
    • Was it in the morning or evening? What time was it?
  • Where were you when you made that decision?
  • Was anyone else involved in the purchasing decision?
    • Why?
  • Visualize the environment you were in when you made the decision to purchase…where were you? What was around you?
  • Tell me more about that…(When you hear something interesting/intriguing)
  • Did you consider any competitors? Which ones? Why?
    • Why didn’t you choose them?
  • How did you decide between what you bought and the other options?
  • Why specifically did you buy that day versus any other? Why then? What was unique about that day?
    • What else were you doing that day?
    • Did anyone contribute to sparking the decision that day? Why?
  • What were you using before you had X?
    • Why did you use that? What did you like about it?
    • When did you start using that?
    • What were its shortcomings?
    • What does the new product do that your old solution couldn’t?
  • How do you normally approach choosing a new product?
    • What was your process for this product?
      • Why was it the same/different this time?
  • How do you use the product you’ve purchased?
    • Are there features you use all the time? How?
    • Are there features you never use? Why not?
  • If in doubt, ask them to tell you more about whatever tangential thing they bring up in the discussion.

You’ll notice as you do the interview, certain moments on the timeline will fit what they’re describing. I wouldn’t try to fill in the timeline perfectly until after the interview, but while you’re interviewing you can mark in your notes when it seems like it fits with some part. If a certain area isn’t seeming to be filled in, probe more around that part in their process.

But will this work in my situation? It’s special/hard/unique.

If you can get the interviewee on the phone or to meet in person, then this will work in your situation. I have seen this work for all of the following cases:

  • Buying a car
  • Buying a scanner
  • Buying steaks online
  • Upgrading to Evernote Premium
  • Buying analytics for their business
  • Getting a gym membership for the first time in their life
  • Understanding why customers churned a SaaS product
  • Buying a 2nd iPad for a family with children
  • Buying a milkshake from a fast food chain

Even if multiple people are involved in the decision making process, any one person in the process is likely able to recall most of the key moments.

What have you used Jobs To Be Done for? What are your favorite JTBD interview questions?

The Concept – Product Chasm: The End of my Lean Product Management Tool & Rediscovery of Passion’s Importance

For the past couple of months I’ve been working on ideas in the lean startup space. As explained in previous posts, it seemed logical: I have a solid background in it from my days at oneforty as well as consulting before and after and the subject is hot now with Eric Ries’s book out, Steve Blank’s book coming soon and a seeming never-ending discussion about the principles in our community.

After initially exploring the opportunity to provide tools for performing customer development, I pivoted to the broader idea of providing a tool to help with Lean Product Management. Initially, the response was great; I wrote a blog post on the concept of Lean Product Management and it was universally loved. It’s the most read blog post on my blog ever and it generated significant inbound interest.  At the same time, I talked to quite a few people that had interesting feedback on the process and where they were coming up short. I also met a number of people and companies that needed help in the areas I was looking for the product to work. However, in the end, a few major issues are leading me to place this idea on the scrap heap with the other previous 8 ideas I’ve evaluated over the past year.

The Concept – Product Chasm

The biggest problem in developing this idea was a major gap between the buy-in to the concept I wrote about and the actual execution of the concept.

In the product management world, it seems everyone has a different way of implementing it. Some people are absolutely hardcore and have impeccable wikis and project management tools (like a 1-2 punch of Jira and Confluence). Others keep it loose with simply a Google Spreadsheet and a Kanban board (both real and virtual).  Finally others have utter chaos and have absolutely destroyed their project management tool by jamming everything in there (usually Pivotal Tracker or BaseCamp).  It seems individuality is greatly valued in the world of product management…

This presents a series of problems:

1) There is no silver bullet

The difference between a Kanban board and a wiki based product management tool is significant. This would mean any tool that was valuable for one is unlikely to be interesting to the other.

2) Marketing is a nightmare

With everyone having their own ideas on how to implement product management principles, targeting and acquiring a customer would be extremely difficult. Even those that I confidently believed had problems in their process often either A) did not perceive there was a problem or B) even if they knew they had a problem, they weren’t actively seeking a solution.

3) There was no MVP

As I talked to over 40 people who owned product at their company, I found no consensus on what part of the process was broken for them; without this consensus, there was no way to build an MVP. More importantly, the lack of consensus showed no agreement on a core problem which could be used as the tip of the spear towards acquiring customers and building out a platform over time; building a Lean Product Management tool would take significant time to become a complete, full life cycle solution, but there was no clear path for doing so.

A Greater Problem – Passion?

One of the most fascinating things about my trip to Silicon Valley in December was seeing how entrepreneurs interact with one another there versus here in Boston. Specifically, I’m talking about the first questions an entrepreneur is asked about their startup/idea. There is no right or wrong here, just different.

In Boston, common questions are:

  1. What stage are you at?
  2. How will you make money?
  3. Do you have any customers?

In the Valley, common questions are:

  1. Why are you passionate about this idea?
  2. How will you acquire customers?
  3. What is the big vision for your idea?

Of all the questions, the one I found most jarring was, “Why are you passionate about this idea?”

Over the past 9 months of questing for an idea, I’ve been attacking ideas with laser focus and rigid customer development methodology. While this has likely saved me a lot of time on any of the ideas, it also was devoid of the thought of passion; was I ever really passionate about an idea in the moving industry or restaurant services? Being completely honest with myself, I don’t believe I was.

Rebooting – a Focus on Passion

Paul Graham, amongst many others, has always said, “solve the problem you wish someone would solve for you.” I actually have an Evernote full of “hack project ideas” that are just that. I plan to start looking hard at those ideas and working on approaches to test those ideas.

Jason Baptiste wrote a blog post back before Cloudomatic (which came right before he and his cofounder discovered the OnSwipe opportunity) which covered a series of ideas he was thinking about. He got a great response from people showing who also cared about the ideas. I may do the same soon.

Embracing Fate

I had a great conversation with Eric Paley after a Dart Dinner early this past fall about my struggles to find an idea. He told me, “I think founders have to believe in a little fate; the right idea will find you at the right time.”

Those words have stuck with me and ring true with my first real venture: Greenhorn Connect. I could not have had that idea come to me at a better time both personally (it was the only way for me to build credibility in the Boston startup ecosystem and land a job 4 months later at oneforty) and for the ecosystem (October 2009 was the very beginning of our ecosystem’s awesome resurgence…the perfect time for a uniting site).

More importantly, I wasn’t even looking to start something when Greenhorn Connect happened. It just grabbed me and I couldn’t not do it. As many of you who knew me then may remember, I was a man possessed to make it work. Despite all the obvious reasons not to do it, I still did it (Lean Startups principles would have definitely it shot down). I will never forget my first Mass Innovation Night after launch and Adam Marchick and Michael Cohen both giving me the proverbial “You’re crazy. Why are you doing this?” speech. Both are great converts now, but it was only the passion and a touch of fate/destiny/luck that really possessed me to so blindingly go after the idea.

After 9 months of trying to force ideas, I’m trying to get back to basics. I need to find my passions and try to let the right idea find me instead of desperately grasping in the dark for ideas or trying to force an idea through the grinder.  A quote from Drew Huston has stuck with me in this process.  He said that of all the 5 or 6 companies he’s started, only Dropbox felt like,the wind was at our back.”  That feels telling and reminds me of the commonly discussed need of Skill, Luck and Timing to build a truly great company.

Alternate directions

It’s been 9 very long months since I left oneforty. While even today I have a runway left that most young entrepreneurs would envy, I’m realistic about my endeavor to start something; how long should you stick with it before you realize the timing isn’t right?

The great entrepreneurs say it takes Skill, Luck and Timing to build a great company. I believe I have the skill to build a great company, which is why I left oneforty. I was also inspired by this oft-tweeted blog post encouraging you to quit your job and start a company even if you don’t have an idea. However, as time continues to slip by, I ask myself if I’m making the most of my time.

That’s why I’m beginning to evaluate working opportunities for the first time since I started this process.

I’ve thought a lot about the framework of what I’m looking for; not needing the money gives me the luxury of weighting all my other priorities over compensation. I’ve realized the most important things to me are:

  1. Working on a really big idea
  2. Working with a truly great leader I can learn from
  3. Having the opportunity to further develop skills that are assets to a business founder

No Regrets

I have ZERO regrets of how I’ve spent my time since leaving oneforty. I’ve learned a tremendous amount about myself, what I need in a technical cofounder and thanks to this most recent idea, how to manage product. I’ve also continued to build my network which is filled with mentors I know I can count on for help when I need it and people I can’t wait to invite to join me in working on that great ideaI know I’m going to find.

Like Steve Jobs said in his Stanford Graduation speech, “you can’t connect the dots looking forward; you can only connect them looking backwards.”  If you found me 3 years ago and told me I’d have done the things I’ve accomplished thus far, I wouldn’t believe you. However, looking back I can see how critical each step was in this crazy journey. Frankly, the less logical the next step, the more it seems to have worked out for the best.

I can’t wait to see what’s next and hope you’ll stay tuned; my beliefs are unshaken: I will build a great anchor company one day.

The Lean Product Life Cycle

See my previous post to understand how I got here. The hypothesis is that product development is messy except for the most disciplined. After talking to a number of great product people, I have a theory for how great product can be developed while being customer centric (aka lean).

The Virtuous Cycle of Lean Product Development

The Product Management Funnel

I think of product management as a funnel. At the top are all of the ideas your team generates. If you’re a lean startup, that’s hopefully driven by customer interviews, website and landing page behaviors and support interactions and of course the occasional green space wild idea.

As product manager, this is the most dangerous step. Once you have more than a few employees, it’s easy to have these ideas overflowing and interfering with the whole product process. Multiple teams I spoke with have been using their project management tools to capture these ideas which leads to a huge mess (one such company had over 4,000 stories in their icebox!) and a major time suck (one vp of engineering is spending an hour + each day managing these ideas).

The problem is project management != product management. The only thing that should be in your project management tool are key bugs to fix and what you’re building now or in the very near future (ie next sprint). Everything should be clearly defined and in a language and structure preferred by your engineers. All the evolution of the product from idea to customer validation to final prioritization should be done outside the project management tool.

The Rest of the Funnel

The Full Product Funnel

Going back to the beginning, you need discipline at the top of the funnel; the best product people I spoke with are requiring a shred of data tied to an idea to make it into their coveted ideas list. They also often expect a disciplined approach to what goes in by having people state, “Feature X will move Metric Y by Amount Z” so it’s clear why the feature needs added. In earlier stages that may be in a “Hypothesis vs. Metric to Invalidate” format instead.

The key of this step is effectively managing the signal to noise ratio; for every 5-10 ideas that come in, you may only make 1 or 2. Even the less disciplined product managers I spoke with have some type of hot-lukewarm-cold system for trying to rank ideas. To avoid the 4,000 stories in your icebox (or anywhere else) you have to be disciplined on dropping stale ideas and focusing on what matters now. When you’re a growing startup, where you were 3 months ago is dramatically different from where you are now so why keep those stories cluttering your system now?

After wrangling the initial feeder of ideas under control, you need to effectively refine the ideas that make it into your system and allow the most important ones to rise to the top of your list. As planning for your next sprint begins, you need to prioritize these ideas and balance with other existing projects, bugs and other demands.

Once you’ve settled on what you’re going to have engineering build next, you need to engage your team on the ideas you want to implement; you may need copy from marketing, stories from support to describe customer complaints, links or screenshots from analytics to show present activity and relevant customer development notes. All of this feeds into the project management tool you have, but now it’s uncluttered and your engineers are much happier and efficient. Unless you’re github or heroku, chances are your engineers don’t understand the customer they’re building for perfectly so all this structure makes it easier for them to see what’s going on and then adapt it to fit the project management tool they’re using to track building.

As an added bonus, there’s transparency for your other employees as they engage in more than just the initial ideation process. It also means sprint planning no longer needs to have all hands at it as they’re already well aware of what’s going on and have had opportunities to contribute as needed to the stories now being generated in the project management tool.

Completing the Virtuous Cycle

We all know this image so well as the core of what lean startups is all about, but how often is this cycle cleanly implemented? The project management tools out today all do a great job on the build aspect, but what about measure and learn?

The funnel process I described above captures the learn aspect as you engage your team for ideas and validation. All that’s left now is to measure.

After you build something new in your project management tool, your engineers will submit it for some form of approval. Once approved, it universally ends up disappearing into the ether, because the project management tool is built to track what you are building or about to build. After building isn’t part of their process.

To close the lean loop, you need to look back and see if that feature actually moved the needle. This needs to happen within 2-4 weeks of building it; sooner wouldn’t be enough data and longer would be distorted due to other things you’ve likely built by then. This last step of learning should help you refine your instincts and feed back into what you build. This is one of the biggest challenges as Eric discusses his principle of Innovation Accounting in his book.

The amazing thing I discovered in so many of my interviews was how rare it was to do this measure step; how can you improve your accuracy without seeing if you hit the target?

The Product – Lean Opportunity

What started as an investigation of lean startup opportunities has broadened to helping teams close the loop in managing a product lifecycle. I believe there is tremendous opportunity to build a platform to aide on both sides of the project management tool and much wider than those adopting lean concepts officially (as we all know, being customer centric is not a new concept).