Build the Right Things Faster

A Practical Exercise to Align Product Engineering Teams

Most teams are solving the wrong problems really well.

They're laser-focused on their corner of the product, polishing features and optimizing flows. Meanwhile, the human on the other side of the screen is cobbling together workarounds, switching between six different tools, and muttering under their breath about "why doesn't this just work?"

Your users don’t think about your product nearly as much as you do. They’re busy thinking about getting their job(s) done.

I use a simple framework that leverages Jobs to be Done to solve this disconnect for teams of all sizes, but in particular, product engineering teams — the teams of engineers working with users, settings goals, and making product decisions. It gives clarity on what actually matters, and has reframed roadmaps for the teams I've worked with.

Where JTBD Falls Short

Quick shared understanding: Jobs to be Done (JTBD) is a research approach that looks at the specific tasks and workflows people are trying to get done in their daily work, beyond just how they use your product. Rather than focusing on user personas, JTBD digs into the bigger picture of what's actually happening and why — the steps before and after someone touches your SaaS tool, the hacks they've cobbled together, and where things break down in their real processes.

The problem? Most JTBD work stays theoretical. (This is also true for a related artifact, the Customer Journey Map.) It becomes a piece of art sitting in Notion or Confluence, gathering digital dust. Beautiful research that never influences a product decision.

To make JTBD practical, you need to merge it with the product lens. You need to connect the human job directly to your product reality — where you're winning, where you're failing, and where you should focus next.

The Exercise: A Simple Table

Create a table with the 8 columns below — 4 to capture the human job to be done, and 4 for your product. Use a Notion database, a table in your wiki, a Google doc, or even pen and paper. It should look like this:

Let's say we’re building a marketing platform, and we’ll use a job typically associated with a Demand Gen Manager at a B2B SaaS company as our example. This person sits between marketing and sales, responsible for driving qualified leads and proving marketing's impact on revenue.

Focus first on the JTBD (the first 4 columns):

Start with the Job (simple shorthand description) and the Job to be Done. Just take a crack at it based on what you already know from your customers or try the prompt below: "When I [situation], I need to [motivation], so I can [desired outcome].”

Then move on to Frequency (how often the user does that job) and Impact (how crucial that job is to them).

💡Just because users do something frequently doesn't mean it's strategically important or impactful to their daily workflow or success, and the converse is also true.

Want a headstart on JTBD? Try this prompt with your favorite AI tool, then take the output to validate and evolve with real users.

As an expert user researcher specializing in Jobs to be Done methodology, I need you to identify 3-5 Jobs to be Done for a specific user in the [INDUSTRY] industry. The persona is often a [JOB TITLE] at a [COMPANY STAGE] company, and I'm specifically looking at their workflow around [SPECIFIC SITUATION/PROCESS]. [ADDITIONAL CONTEXT: team dynamics, current pain points, goals, constraints, or tools they use]. For each job, provide: 1) Job (short name), 2) Job to be Done using the format "When I [situation], I need to [motivation], so I can [desired outcome]", 3) Frequency (how often), and 4) Impact (High/Medium/Low). Focus on jobs that are currently underserved or create friction in their workflow, considering both functional and emotional needs.

Now move on to your product with the next four columns:

Current Priority. Only you can answer this. Focus on your goals for the next 6 months, and be judicious about what rows you assign high priority. Some jobs — low impact, low frequency, etc — might not even carry willingness to pay. Also think your product vision and the type of company or product you’re building:

• Point — Teams focused on solving specific pain points might intentionally keep many JTBD rows low/no priority. An example might be a company like Carrd, where many jobs for their users might be unaddressed because Carrd is hyper-focused on a niche, specific use case, while a Squarespace might want to tackle many more.

• Compound — Teams focused on building compound products/startups, like Rippling aim to solve towards many or even all of the rows, but must apply rigorous product thinking around which rows to go deep and differentiated on, vs parity. A low impact JTBD for a compound startup might led to a decision to integrate rather than build, for example, and they might be okay with a score of 2/5 for a long time.

Lastly, Current Features, Score, What’s Missing. Look at your product and separate out the chunks of features and functionality here mapped to each specific JTBD. Then score it on how well that set of features truly helps the user do that job, and be critical. Put yourself in your users’ shoes. And list the gaps that would increase that score.

Repeat these steps until you’re confident that you’ve got a succinct, accurate view of that person’s responsibilities across 5-10 rows of jobs to be done — even if some of those jobs do not intersect with your product.

What You'll Discover

Most teams discover they're over-investing in jobs they already handle well while completely ignoring high-priority jobs that could differentiate their product. The scoring creates an honest assessment of where you actually stand. It gives your team shared context to ask sharper questions: Which job does this serve? How important is that job? How well do we handle it today?

I was working with a SaaS founder recently who was operating in an industry I was unfamiliar with, so I had some homework to do. After some research, I used this framework to first get inside the customer's head, then asked the founder to help me validate it, and then we paired on each row until we felt like it captured the real human jobs. Then we mapped those to their product.

It became abundantly clear almost immediately where the product was letting users down. We built out a survey, pulled up the data in the analytics tool, and did a few quick user interviews to validate those assumptions. And now, that founder is using this table to help prioritize what's next for their product.

One 30-minute conversation completely reframed their roadmap.

Making It Stick

Here's how to embed it into your product engineering team:

Review it monthly. Jobs evolve as your users and business mature. What was important six months ago might not be today. Particularly helpful if your SaaS product begins to move upmarket — often introducing more personas and more specific roles/responsibilities.

Use it for prioritization. Before adding something to your roadmap, ask: "Does this improve our score on a high-priority job?"

Fast onboarding for new team members. This table gives new engineers user context on the customer quickly.

Take it to customer calls. Validate your assumptions. Are these really the jobs your users care about? Are you missing something obvious? Take the JTBD and reframe it as a question to get the user’s score on how well your product is helping: “When you’re preparing for your monthly revenue review, how well is the product helping you prove which marketing activities actually drove closed deals…?”

Reference it in specs. When writing requirements, connect features back to the jobs they serve. This helps engineers understand not just what to build, but why it matters to the user's workflow.

⚠️ An Aside on Personas

Before we wrap…short rant.

You might be asking how this relates to personas. You know, those perfect, imaginary friends who promise empathy, user-centric thinking, and clarity in product decision making. Goodness, the time I spent crafting the page-turning biography of “Marketing Maria” — her role, company, favorite coffee order, and t-shirt size…

My issues with putting personas on a pedestal:

1. Real users — unique humans with specific motivations — are messy, and don't fit neatly onto a card.

2. Why chat with users if you have a persona to represent them? Knowing that "Marketing Maria" is 41 and loves running doesn't help you build a better product; go talk with the actual Maria.

3. Personas often emphasize attributes over actions, leading to decisions based on who users are, rather than what they need to accomplish. Something a JTBD focus solves.

Put JTBD first, and let personas play a supporting role.

</rant>

The Real Value

This exercise around JTBD will save you from building features nobody uses. It's the fastest way to align your product engineering team around what actually matters.

Your team(s) should be asking questions like: Which job does this serve? How important is that job? How well do we handle it today?

I've used this approach with early-stage teams who felt stuck, growing teams who lost sight of their users, and established teams who wanted to find their next area of differentiation — like expanding their product footprint into adjacent jobs and personas.

The better context teams have, the more they get inside the user's head, the better decisions they make.

---

Ready to Build What Actually Matters? Try it with your team this week. Build the table, fill out 5-10 jobs, and take a step back. You'll know exactly where you're winning, where you're failing, and what to build next.

Need help facilitating the exercise or want a fractional product leader who can embed this user-centered thinking into your team's DNA? Let's talk: arborproductsolutions.com