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.

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.

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?

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.

1. Empathetic Perspective
2. Uncovering Demand
3. Causal Structures
4. Prototyping to Learn
5. 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.

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)

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.

“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” — Theodore Levitt“You must learn to see the world through the customer’s eyes — not through the lens of your product.”

“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### JTBD Timeline

Definition: A zoomed-out look at the customer journey from dormant discomfort to active progress.

1. First Thought

• 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

• 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

• 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

• 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

• 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

• 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

“This is either going to stick… or fade out like the others.”### 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.

Example: Instead of building another workout tracker, you discover people really need non-judgmental support after failure. So you build that first.

“Let’s see if this actually helps.”### Over-Served / Under-Served Jobs

• Example**:** Advanced macro breakdowns Winston never looks at.

• 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.

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.