It's amazing to me what a skill it truly is to be able to talk to customers/users, and come out of those conversations with valuable/actionable insights.
As an engineer, it's _so_ easy to fall into the traps she mentions ("not really listening to your users and [...] building something you think people want", or becoming "more focused on the excitement of the technical challenge than your users").
Until I actually tried starting a business, I always scoffed at this advice -- "obviously I won't make those mistakes!" But I still find myself goofing up over and over. It's so attractive to think that "this one new feature will make all the difference, so I should probably just focus on coding rather than talking to users."
Has anyone found a particularly effective way to overcome this? Is it just a lack of discipline on my end? (Maybe I need to reread "The Mom Test" a few more times...)
It's discipline and systems. The fewer systems you have in place to enforce correct behavior, the more you have to rely on discipline. And discipline is a tough nut crack consistently.
Some of my favorite systems include:
* Social accountability. The human desire to appear reliable and consistent is a power to be taken advantage of. Get a partner, a co-founder, a mentor, an investor -- someone that you have to answer to occasionally. Tell them your plans, and check in with them to review your progress regularly. In other words, set yourself up to suffer a bit of embarrassment if you don't live up to your word.
* Batching. It's been said that you ship your calendar. If you think 40% of your time should be spent talking to customers, block off 40% of your calendar for that task. Don't allow yourself to write any code during that time. This is easier if you batch your work together. For example, I do this for my podcast. No coding allowed on Mon, Tue, and Wed, only podcast work.
* Front-loading. I have very little willpower to make the right decision in the moment. When I'm hungry, I'll turn to junk food. So I try to pick a singular time when I'm in the right headspace to make the right decision for my future self. I grocery shop when I'm full, fill my fridge and pantry with healthy food, and rob myself of the ability to make bad choices later. You can do this with customer conversations, too. For example, on Monday schedule calls for the next two weeks. You'll be more-or-less obligated to have those calls when the date arrives no matter how you feel at the time.
* Time boxing. Most of us are procrastinators. Procrastinators get the bulk of their work done just before a deadline. Use this to your advantage by setting lots of deadlines, which should ensure you have lots of productive periods. Make sure they're deadlines you can't break. I like to combine this with social accountability, meaning my deadlines are scheduled meetings or outings with other people.
1. Find the pilot customer first. Ideally more than one. Build and iterate with their guidance.
2. Do your own support. This is easy; when you're small, there's nobody else to do it. Use chat-type support apps like intercom so that every interaction is a conversation.
It helps to be somewhat of a people-pleaser by nature. Just make sure you're putting your effort into pleasing the right people.
I think the best way to overcome that is being brutal about releasing early and often. If you are shipping to actual users every few days and then seeing how users react to the new thing, the occasional goof isn't a big deal. Indeed, it's a great way to learn some valuable humility.
100%, "bias for action" as they say. Delivering something regularly and creating a loop that including customers/users etc will help form good habits. Lots of positives will flow from this I've found.
I am very adamant about following a strong scrum cycle (although, I'm loose with the details).
* Build a backlog
* Run a sprint (I like 2 week sprints at startups)
* Don't put anything new in the current sprint unless absolutely necessary.
* Rinse and repeat
The simple nature of having a "waiting" period for new features helps put perspective on them while giving you time to make sure they're broadly useful. If only a single person is asking for them, wait to build.
> Don't put anything new in the current sprint unless absolutely necessary.
As Jason Fried of 37Signals would say, "Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, scope window."
I have this temptation too. Its hard to juggle between programming and talking to users. There are on the opposite ends.
I have been able to finish a task at least 50% of time faster just by talking to users.
Now I delay the first line of code until the estimate squeezes down to a few days or a week max. Anything more and I am back to research and communication mode.
I used a simple trick which is to fall way behind on my coding chops then take a leadership role in an org where I'm not at all familiar with the tech stack. I like to think I was a pretty sharp developer 10 years ago and now I'm practically useless. So focussing on my communication and leadership skills has been a necessity.
Yes, only build those things that will increase usage metrics. Get daily feedback from users and delight them with your solutions. Rinse and repeat to greatness.
Talk to your intended audience to figure out what they want to accomplish, not just the tools they ask for.
This is a useful way of looking at things. Yet, there is a limited distance we can expect the audience to traverse before using what they are familiar with. The number of fax machines in existence shows the staying power of habits.
As a startup, look at the decison/control points specific to the 'job to be done'. This is a game of revealed preferences and principle-agent problems.
I think approach this article talks about is more in the line of "People don't want a drill, they want a bookshelf on the wall".
Two very different approaches to "Jobs to be Done" exist: one is about helping make better holes, and another is targeting the reasons for drilling the hole, reframing the problem itself. I found that former approach helps deal better with something habitual, like re-designing some existing product (faxes..) or adding features, while latter helps to ideate completely new solutions.
Exactly! So the drill is entirely optional if you have something like tape. Or a railing or a piece of wire.
It's crazy how often my clients ask for a solution for me to cod while a way cheaper one / pragmatic one can be done in minutes that is enough for them to test the hypothesis for their product market fit.
The best book on this subject is Clayton Christensen's "Competing Against Luck", where he details the 'jobs to be done' paradigm. It's a great book which contains his usual combination of empathy and insight, and I recommend it to all.
If anyone’s looking for a guide to implementing JTBD, I can heartily recommend Jim Kalbach’s recent book The Jobs To Be Done Playbook [0]. Jim works for Mural (collaboration SaaS), and has a refreshingly real-world take on Jobs.
Nice article, thanks for sharing! I first read Clayton Christensen's Competing Against Luck and was excited by the case studies.
To make it actionable, I bought Alan Klement's When Coffee and Kale Compete (yes bought, worth the money, but you can download for free).
That left me with an underwhelmed feeling. Not that I didn't like to book, it's great! I lend it out to a colleague immediately. But it's still not actionable.
This article provides a very simple, yet effective, template to capture and share jobs. Could apply it directly on a research project I'm working on.
I have been using JBTD for any content I write. It helps me set goals and stay on track. Not get lost in vivid ideas and random advisory.
From a product standpoint, I use the job descriptions (from job boards) of target roles (users) and identify where my product plays role. This works for business users because we only care about individual roles in company.
> Do the work to make sure you are building a product that people will actually find valuable
Real rich coming from a Facebook employee...
The big problems we face today are not supply-side gaps startups can help with. There gaping macroeconomic fuck-ups, either demand-side or unaccounted externalies supply-side. Startups cannot directly help with those very well. Better they nudged the economy to a new equilibrium after the goalposts are fixed.
Fine if you want to do a startup now, but no need to be a on a high horse about it.
Can anyone give me an idea how this fits with or differ from mission statement/value prop? Is it suppose to be more concrete than mission statement? Do company need both?
Mission Statement is what drives your company day in, the how you are gonna get to your vision statement.
The Value Prop is the "problem" you are solving - jobs to be done helps you find the problem. The Value Prop is really the problem as described by your customers using their language.
IMO mission statements are for your employees - same with vision - and your overall brand. Value Props/Jobs you help customers accomplish are what you build your features around.
As an engineer, it's _so_ easy to fall into the traps she mentions ("not really listening to your users and [...] building something you think people want", or becoming "more focused on the excitement of the technical challenge than your users").
Until I actually tried starting a business, I always scoffed at this advice -- "obviously I won't make those mistakes!" But I still find myself goofing up over and over. It's so attractive to think that "this one new feature will make all the difference, so I should probably just focus on coding rather than talking to users."
Has anyone found a particularly effective way to overcome this? Is it just a lack of discipline on my end? (Maybe I need to reread "The Mom Test" a few more times...)