How I Ship 50x Value In The AI Era
First principles for AI Products: A JTBD Approach for Product Engineering in The AI Era
Disclaimer: This article only scratches the surface of the Jobs to Be Done (JTBD) framework, product engineering, and AI development flows. The topic is broad and deep, and I’ve only gone as deep as possible for a general guide to teach you how to think like a Product Engineer. There are many flavors of JTBD as well (per Bob Moesta, creator of the frameworkFrameworks and tools are only as powerful as the person wielding it. JTBD is not a checklist; it is a framework where success is a function of your breadth and depth of skills required to execute on the methodology well. The deeper your empathetic perspective, and your understanding of causal structures, customers, and systemic design, the more effectively you'll ship value.
I recently got the chance to work with Bryan Johnson and his development team on AI Bryan, to help users improve their longevity protocol.
I loved working with their tech team—in particular, shoutout to Greg, Chris, and Ryan from the engineering department! ❤️
Our engagement with them, was to help with LLM architecture, AI evals, and map out the value to users and experiments to iterate. We ended up shipping it to Beta with a couple hundred users.
I’m going to show you how I approach building like a Product Engineer in the AI era, to ship relevant value at 50x speed.
It was a great opportunity to apply my new learnings and tools from the rapidly evolving AI landscape to help answer a single question:
Why did they hire AI Bryan?
In this newsletter, I’ll explain the tactics I used to execute on answering these questions.
I cannot reveal anything confidential, and so I’ll speak with general examples and use cases that would be true for most AI Health Coach use cases—aka help the user get generally healthier.
And you’ll soon see that even “healthier” is ICP (Ideal Customer Profile) dependent.
And that’s why Product Engineering is so important in this AI era.
I have seen lots of questions about what tools to use, or what products are best.
I find that Product Engineering is much more about how to think and solve problems, than it is about tools.
Zooming Out… Software is Changing (Again)
Before we dive into Product Engineering in the AI era and the methodology, let’s zoom out and talk about where Software is going as a whole.
In engineering, defining the problem well is key.
Knowing the macro situation of where we are at in this point in time, as an industry, is key to better executing on the day to day micro situations and decisions we face (engineering problems, product problems, design problems, etc.).
Andrej Karpathy, founding member of OpenAI, former Senior Director at Tesla, recently shared his vision of how Software Is Changing (Again) at Y Combinator’s AI Startup School in San Francisco.
Karpathy makes the point that Software has evolved significantly over the last few years, more than in the previous 70 years, transitioning through three paradigms.
Software 1.0: Traditional code written by humans to program computers.
Software 2.0: Neural networks, where the program is defined by the weights learned from data.
and now…
Software 3.0: Large Language Models (LLMs) programmed through natural language prompts, effectively making English the programming language.
This evolution signifies a shift toward more human-like, flexible, and accessible computing.
Builders today must understand these paradigms to leverage their strengths, adapt to a hybrid software landscape, and prepare for a future where programming becomes more democratized and autonomous systems play a larger role.
"If you're entering the industry, it's a very good idea to be fluent in all of them [Software 1.0, 2.0, 3.0]. Because they all have slight pros and cons, and you may want to program some functionality in 1.0, 2.0, or 3.0." —Andrej Karpathy
So now that we know the macro, we are 100% confident that the best builders of the future will require the skill of optimizing throughput of quality decision making to ultimately deliver value to users, as fast as possible.
AND build something that lasts the tests of time and scale.
That’s where Product Engineering comes in.
Software engineers traditionally focus on building high-quality systems that are scalable, reliable, and efficient.
They care deeply about implementation details and system design.
Product engineers still write code—but they orient their decisions around user needs, business goals, and speed of feedback.
In some companies, the two roles are the same.
In others, they’re distinct.
The industry is evolving so rapidly that the lines between traditional roles in the software development lifecycle are blurring.
I have a hypothesis that we’re all going to just be “builders of the future”. We do what it takes to deliver value and solve customer problems.
Why This Matters Now
Let’s get to first principles—when we ship products, it is all about maximizing learning rate and shipping value at the speed of relevance.
What do I mean by this?
If value is the X on the map, and we’re pirates—then it is whoever reads the compass and navigates the ship best to find and maximize customer value, that wins.
Relevant shipping.
In the AI era, the edge you have is to maximize relevance and learning rate.
That’s where Software 3.0 is especially useful as a tool.
This newsletter will give you a crash course in how to combine the Jobs to Be Done framework, one of my favorite product management and entrepreneurial tools, with rapid prototyping to uncover what your users are really hiring your product for.
I will couch everything in the example of a general AI Health Coach, similar to our team’s engagement for AI Bryan.
By the end, you’ll walk away with:
A tactical understanding of the JTBD framework
A phased workflow to discover causal structures and fast-forward your roadmap
A real-world (generalized) AI Health Coach example of Product Engineering
And then?
Ship value at the speed of light.
JTBD 101: The Real Question Is... Why Do People Hire Your Product?
"People don’t want to buy a quarter-inch drill. They want a quarter-inch hole." — Theodore Levitt
Or in Henry Ford’s case, they didn’t want a faster horse. They wanted to get from Point A to B faster.
That’s the essence of Jobs to Be Done: your product is a hired hand.
Its job?
Help users make progress in their lives.
Let’s start with some definitions grounded in Bob Moesta’s 5 skills of innovators and entrepreneurs. This will take some time to sit with, but it will be well worth it to execute well as a Product Engineer.
Empathetic Perspective
Uncovering Demand
Causal Structures
Prototyping to Learn
Making Tradeoffs
All 5 are incredibly important, though I would agree with Bob Moesta that the Empathetic Perspective is the foundational skill of innovation.
It unlocks all the others—it is the one that helps you maximize learning rate and navigate the compass to relevant shipping and value best.
Without it, you are simply projecting your own assumptions onto the customer instead of understanding their lived reality.
“You must learn to see the world through the customer’s eyes — not through the lens of your product.”
Bob emphasizes that innovation begins with humility.
You have to suspend your own solution logic and get curious about the customer’s context, progress, and constraints.
So let’s get some definitions clear, with supporting illustrations from Bob himself.
Job To Be Done (JTBD) Key Terminology
Definition: The progress a person seeks in a specific context.
Example: Winston doesn’t just want an app. He wants to feel in control of his health again, and feel confident in himself in social settings.
Main Job
Definition: The core outcome the user is trying to achieve.
Example: Lose 10 lbs sustainably without feeling like a failure.
Related Jobs
Definition: Additional progress the user wants to make alongside the main job.
Example:
Functional: Track meals and calorie intake without tedious data entry.
Emotional: Feel proud of myself after each healthy choice.
Social: Be seen by my partner as someone who’s “got it together again.”
Struggling Moment
Definition: The tipping point when the user’s current situation becomes untenable.
Example: Winston tries on a shirt that no longer fits. Later that night, his partner says, “You’ve really let yourself go.” That comment becomes the trigger.
Four Forces of Progress
Bob talks a lot about the four forces of progress in the system. Here’s a helpful illustration.
Push of the present: “I feel sluggish every morning, and I hate what I see in the mirror.”
Pull of the new: “This AI Health Coach looks like it’ll help me stay on track in a gentle, consistent way.”
Anxiety of the new: “What if this is just another app I use for a week and quit?”
Habit of the past: “I’ve always tried to fix things with willpower alone — I don’t trust systems.”
Three Types of Energy (Motivation)
Functional: Log my steps, calories, and workouts daily.
Emotional: Avoid guilt after a slip-up.
Social: Feel confident enough to wear a swimsuit at the beach with friends.
Job Statement
Definition: A structured sentence that describes the job in a way that’s independent of the solution.
Format: [Verb] [object] [context]
Example: Maintain healthy workout and eating habits while juggling a stressful full time job and being a dad.
Causal Structures
Definition: The sequence of cause-and-effect events that lead to product adoption or rejection.
Example:
Winston gains weight →
gets a harsh comment from his partner →
feels ashamed →
searches online for help →
discovers the AI Health Coach →
downloads the app after reading reviews →
logs first meal →
gets a badge or celebration from the AI →
feels a small win →
continues the next day.
JTBD Timeline
Definition: A zoomed-out look at the customer journey from dormant discomfort to active progress.
1. First Thought
“Something’s off... I need to get a handle on my health.”
Winston notices he’s out of breath after climbing stairs.
He feels uncomfortable in photos.
A creeping sense of dissatisfaction begins — but it’s vague.
No action is taken yet, just a growing discomfort.
2. Passive Looking
“I’m not ready to commit, but I’m open to inspiration.”
He watches a YouTube video titled “How I Lost 10 lbs Without Dieting.”
Scrolls past a Reddit thread on accountability apps.
Sees a friend’s fitness progress post on Instagram and feels a twinge of envy.
Still hasn’t searched directly, but mental awareness is rising.
3. Active Looking
“I’m officially in research mode.”
He searches Google for: “AI accountability coach for weight loss.”
Downloads a few apps (Noom, Bryan AI, MyFitnessPal).
Compares testimonials, UI screenshots, pricing.
Reads reviews to gauge emotional tone: “Is this app going to shame me?”
4. Deciding
“This one feels right for what I need right now.”
He chooses Bryan AI because it frames progress around compassion, not perfection.
The testimonial “Helped me forgive myself and stay consistent” resonates deeply.
He deletes the others before even logging in.
5. First Use
“Let’s see if this actually helps.”
He’s greeted by a warm onboarding sequence.
Logs his first meal.
Gets a personalized message of encouragement: “Progress is built one choice at a time.”
Thinks: “This is different.”
6. Ongoing Use
“This is either going to stick... or fade out like the others.”
After a 4-day streak, he misses a day.
Instead of guilt, the AI Health Coach nudges him with: “Yesterday’s gone. What’s one kind thing you can do today?”
Winston logs back in.
A sense of trust builds. He’s not perfect — but he’s still showing up.
He gets back on the wagon
Hire / Fire Criteria
Because this framework centers on the user hiring the product or service for a job, thinking about hire and fire criteria is very useful.
Definition:
Hire: Start using a product for a job
Fire: Stop using a product that no longer serves the job
Example:
Winston fired calorie counting spreadsheets.
He hired Bryan AI because it felt simpler and more emotionally supportive.
Demand-Side Innovation
Definition: Building products based on the customer’s life, not your roadmap.
Example: Instead of building another workout tracker, you discover people really need non-judgmental support after failure. So you build that first.
Over-Served / Under-Served Jobs
Over-served: Too many features for something people barely care about.
Example: Advanced macro breakdowns Winston never looks at.
Under-served: Real jobs where current tools fall short.
Example: Emotional recovery after failure — no app gives Winston permission to be imperfect and keep going.
Switching Behavior
Definition: The decision-making and emotional journey someone goes through when replacing a product.
Example: Winston had tried getting healthy before but he was overwhelmed with all the information when he tried. He didn’t know where to start—diet or exercise? Both of those go so deep. He switched to the AI Health Coach after seeing one testimonial: “This app helped me feel good about myself again, and even though it was a bumpy ride to get to my health goals—I got there!”
Customer Progress
Definition: The ultimate value people seek — not features, but movement toward a better version of themselves.
Example: Winston’s real progress wasn’t losing 10 lbs — it was rebuilding his self-trust after years of starting and stopping, and feeling like he deserved his partner again.
Takeaway: You must understand all of these dimensions to truly design value people will use, love, and pay for.
First Principles: Finding the Causal Structures
Building from first principles means stripping away assumptions and discovering ground truths.
Your product and users exist within a system.
Every user interaction is a signal.
Your job is to separate signal from noise:
Control Factors: Tunable variables you can adjust to improve experience, value, etc. (e.g., application evals, notification timing, AI tone, packaging of information and responses, action buttons).
Noise Factors: Variables outside your control or hard to influence (e.g., user stress levels, weekend binge eating, social circle).
By identifying control vs. noise, you stop wasting time A/B testing noise and instead design your system to absorb it—or work around it.
→ So how do you find the causal structures?
You experiment.
Like a scientist.
Design Smart Experiments: Enter Taguchi
The best product teams experiment constantly.
But not all experiments are created equal.
Time and resources are the limiters.
→ So how do you pick and design your experiments to maximize your learnings (to maximize delivered value), in the least amount of time?
You experiment.
Like a hyper-optimizing scientist.
The essence of Product Engineering.
The Taguchi Method is at the heart of the Jobs To Be Done methodology that Bob Moesta co-developed with Clayton Christensen.
It is the best way I have found to design optimal experiments when you have multiple variables but limited time.
Instead of testing every combination (which grows exponentially), this method helps you:
Identify control factors that drive outcomes
Minimize noise factors that introduce variability
Run orthogonal tests — small sets of experiments that isolate effects efficiently
Optimize for signal-to-noise ratio (SNR), ensuring robustness under real-world conditions
In simpler terms: it lets you learn faster with fewer tests.
Let’s Put It Into Practice
Now that we’ve gotten the theory down, let’s start practicing.
Example: AI Health Coach - Daily Check-In Nudge Feature
Assumption: Let’s say you’re interviewing Winston and other users to better understand how you may design a new feature. Interviewing is a whole skill in itself, which I will save for a different post.
Let’s assume for this post, you’ve executed on all the interviews from a JTBD perspective and have uncovered key insights.
Let’s also assume, you’ve recruited Winston and many other users to be early adopters of the new feature.
So you’ve already lined up the interviews for tomorrow.
Ideally, we get a prototype in their hands as fast as possible.
So let’s get to work.
Identify The Causal Structures
Here’s an AI prompt you can use with your favorite agent, given the input of a raw transcript of the user interview.
You are a world class Jobs To Be Done analyst. Given the attached transcript, extract causal patterns, jobs to be done, and emotional signals.
### Instructions
- Highlight the struggling moment
- Identify main and related jobs (functional + emotional)
- Lay out the causal chain
- Pull 3–5 direct quotes as supporting evidence
### ICP Description:
[INSERT ICP DESCRIPTION HERE]
### Product Context:
[INSERT PRODUCT CONTEXT HERE]
### Output Format (Markdown)
#### 🧠 Struggling Moment
...
#### 🎯 Main Job to Be Done
...
#### 🔄 Related Jobs
- **Functional:** ...
- **Emotional (Personal):** ...
- **Emotional (Social):** ...
#### 🧩 Causal Chain
1. ...
2. ...
3. ...
#### 💬 Quote Highlights
- “...”
- “...”From this, we get this output for a fake transcript:
JTBD Analysis for Winston – AI Health Coach Nudge Feature
Struggling Moment
Winston felt a growing sense of discomfort with his health and body image. The tipping point came when his partner made a joking-but-hurtful comment before a beach trip, triggering shame and a desire to finally take action.
Main Job to Be Done
Get back in shape and build sustainable health habits without feeling shame after inevitable setbacks.
Related Jobs
Functional: Stay consistent with health habits without micromanaging data or logging every meal.
Emotional (Personal): Regain confidence and self-trust after repeated failures.
Emotional (Social): Feel attractive and respected in front of his partner and peers.
Causal Chain
Winston notices ongoing low energy and weight gain.
Partner makes a joking comment about how he “used to work out.”
Feels shame and avoidance — doesn’t want to take his shirt off at the beach.
Passively browses health videos and articles.
Searches for non-judgmental health solutions.
Finds AI Health Coach and is drawn to its emotional tone in reviews.
Hires AI Health Coach because it promises a guilt-free recovery path.
Uses the app, experiences compassionate nudges, re-engages after missing a day.
Begins to feel trust and progress, reinforcing new habit loop.
Quote Highlights
“I was feeling off—low energy, just not myself.”
“She made a comment... ‘Remember when you used to actually work out?’ That one stuck.”
“I wanted something that could just help me get back on track without making me feel like crap for missing a day.”
“Every other app feels like punishment when you mess up.”
“It said, ‘Life happens. Ready to try again?’ That made all the difference.”Prototyping To Learn
From this, let’s say you then go back to the team and you do some divergent design thinking and brainstorming.
Your team comes up with a new solution hypothesis/feature—a daily check-in nudge feature for the AI Health Coach for users like Winston who are trying to lose 10 lbs with some encouragement and accountability.
You need to prototype this out, to learn further what is relevant to Winston and other users.
You're testing 4 variables (control factors), each with 3 levels:
Traditional Full-Factorial Approach
If you were to take a traditional approach, the total number of experiments required to get to truth on relevance is a factorial of the number of factors = 3 × 3 × 3 × 3 = 81 combinations
This means you'd have to:
Design 81 distinct experiences
Recruit enough users to test each one
Analyze and compare them all
Hope nothing changed mid-experiment
At the average tech company on the average scrum team, you will not have a chance to do 81 experiments.
Using the Taguchi L9 orthogonal array, you can reduce this to just 9 tests.
And here’s an AI prompt you can use with your favorite LLM to design your experiments:
You are a world-class experimentation strategist and product scientist.
Your task is to generate a Taguchi-style Design of Experiments (DOE) test matrix to optimize a user experience based on limited, high-value tests.
---
### Context:
I am testing a feature inside [INSERT PRODUCT NAME] for the following user:
**ICP**: [Describe user persona and motivation]
**Feature**: [Name and purpose of feature]
**Goal**: [What outcome are we trying to drive? e.g., increase re-engagement, reduce churn, improve retention]
---
### Variable Design:
List 3–5 **Control Factors** with 2–4 **levels** each, e.g.:
- Tone of message: Friendly, Supportive, Direct
- Delivery time: Morning, Afternoon, Evening
- Call-to-action style: Reflective, Action-oriented, Gamified
List 2–3 **Noise Factors** you can't fully control but want robustness against, e.g.:
- User mood, external stressors, time since last login
---
### Output:
- A clear **Taguchi L-array** (e.g., L4, L8, L9, L16) based on the number of variables
- A clean **test matrix** in Markdown table format
- For each combination, output a 1-line description of the variant (e.g., “Supportive tone + Afternoon message + Gamified CTA”)
- Recommendations for how to analyze results and what signal-to-noise ratio (SNR) would indicate robustness
---
### Output Format (Markdown):
#### 🧪 Test Matrix (L9 example)
| Variant | Tone | Delivery Time | CTA Style |
|---------|----------|---------------|-------------|
| V1 | Friendly | Morning | Reflective |
| V2 | Direct | Afternoon | Gamified |
| V3 | Supportive | Evening | Action-oriented |
...
#### ✅ Interpretation Guidance:
- Analyze success metrics (e.g., re-engagement rate) across variants
- Calculate SNR for each factor to identify robustness
- Focus rollout on highest-SNR combo with lowest varianceMaximal learning, minimal time.
From this, we can generate a PRD optimized for an app like Cursor, Base44, Lovable, then throw it in there to prototype.
At this point, we do not care about scalable architectures. We care about the experiment, and maximizing learning rate.
Now we have a prototype, and we have set the stage to test the factors we can control.
From here, you can continue your experiments and progress on learning to ship relevant value.
You will get to the root of the causal structures, and the relevant value for your ICP.
Plan experiments.
Learn.
Repeat.
You’re on your way to being a Product Engineer, using fundamental systems thinking grounded in proper product management.
Note: I have never seen any product team in my career get unlimited time and resources to actually conduct such level of rigorous user research to inform strategy and execution.
However, in this AI era especially after this engagement on AI Bryan, I am feeling much more confident that as tooling evolves and best practices emerge for AI-native development lifecycles—more teams will ship this way.
And that is the foundation of product engineering. It’s a mindset.
Be scientific in everything.
Find all the optimization secrets there are to be found, to get signal from noise and deliver on your customers’ jobs to be done, and show them progress on them.
Because it gets to customer value faster.
Extra Resources
I loved watching this interview and post-interview thoughts by Chris Spiek, a complete expert at interviewing in the JTBD style. It helps you understand how to pull on the right threads that evolve in real time during an interview. Elegantly getting to the heart of the “Why” behind the customer’s decision making is a skill and art.
Liked this article?
💚 Click the like button.
Feedback or addition?
💬 Add a comment.
Know someone that would find this helpful?
🔁 Share this post.
ABCs with Robert Ta is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
P.S. If you haven’t already checked out my podcast, ABCs for Building The Future, where I reflect on my founder’s journey building a venture in the open. Check out my learnings on product, leadership, entrepreneurship, and more—in real time!
P.S.S. Want reminders on entrepreneurship, growth, leadership, empathy, and product?
Follow me on..