A ‘Jobs to be Done’ Framework for Startups
firstround.com
firstround.com
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...)
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.
Even if they don’t pay, you’ve tested the conversation and grounded it in an exchange of economic value.
This gets more intense the longer you’ve invested in it.
It’s so much easier to sit back and tinker.
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.
Can be handy to have a salesperson slap you back into favoring paying customers/profitable niches though.
* 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.
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."
https://medium.com/@mvwi/exhaustive-notes-getting-real-37sig...
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.
"People don't want a drill, they want the hole"
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.
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.
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.
Great outline of these different approaches and mindset behind them can be found here: https://jtbd.info/know-the-two-very-different-interpretation...
Not sure what those "social features" are, but if it's the integration with Facebook it's a massive failure in understanding their users.
[0] https://www.amazon.com/Jobs-Be-Done-Playbook-Organization-eb...
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.
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.
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.
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.