Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies, amplified by AI!

Restarting on purpose

The handbook stops here

The Practical Handbook for Product Developers stops here. Each issue worked like a chapter: one on what building a product means, one on MVPs. Those two are the last of that series. After them, this newsletter changes.

Content has never been the point for me. I write to force myself to understand something well enough to explain it. That’s how I study, and for the past year the thing I’ve been studying is AI: how to use it in real engineering work, not the polished version you see in demos. That question took over my attention, and everything else I was writing about stalled.

What’s next

The second half of 2026 opens with that story, on purpose. Twelve months sit behind it: reflections already settled, reflections still forming as I write these issues, experiments that worked, experiments that failed, and a few ideas barely weeks old that might not survive more testing.

The center of gravity stays where it has always been: XP, Agile, DevOps, the practices that make software sustainable. This isn’t a 360-degree AI newsletter. I’ll read every practice through what AI tools and agents do to it: TDD, refactoring, incremental delivery, code review. General-purpose AI tools and techniques will come up when they matter, but I’ll spend most of that attention on coding agents, because they’re the tool sitting inside our daily work right now.

Same shape, new content

This newsletter stays what it has always been: short, one idea at a time, a few minutes to read.

The blog moves to monthly and goes deeper. The first piece lands around August 28th: “From Curiosity to Craft: How AI Entered My Professional Workflow.”

The podcast comes back this Thursday, August 27th. In that episode, I go further into the pause itself: why it happened, and why now is the right time to restart. It also tries a new format: no more forcing every episode into a 25-minute Pomodoro box. Each reflection gets the time it needs.

Why I’m telling this story

Writing is how I think. It’s sharpened my thinking these past few months more than anything else I’ve done. And when I share it, other people can push back, add what I’m missing, or tell me where I’ve got it wrong. That feedback loop, more than any single insight, is how this field gets better.

This content works for anyone building software, whatever your experience level. The more you bring, the more nuance you’ll catch, but the core ideas should land regardless.

This is a deliberate restart, shaped for a different world. The practices that built technical excellence before still hold, but AI means we have to challenge them, evolve them, and amplify them to keep that excellence alive now.

If that sounds like a conversation worth following, stick around. The podcast picks it up first, this Thursday.

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

1️⃣2️⃣ Chapter 12 – Release in slices

1️⃣3️⃣ Chapter 13 – TDD from day one

1️⃣4️⃣ Chapter 14 – Thin slices for testable software

1️⃣5️⃣ Chapter 15 – Bring the first users early

1️⃣6️⃣ Chapter 16 – Managing Technical Debt from Day One

1️⃣7️⃣ Chapter 17 – The MVP Playbook → You are here!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Why an MVP Needs Method, Not Guesswork

Building an MVP is often misunderstood.

It’s not about building a smaller product.

It’s not about rushing development.

And it’s definitely not about cutting corners.

It’s about:

Maximizing learning while minimizing time, cost, and risk.

Across the previous chapters, we explored how to:

• define the right scope

• build in thin slices

• keep architecture evolvable

• maintain quality under pressure

• involve real users early

This final chapter brings everything together into a practical playbook you can reuse every time you start a new product or feature.

🧭 The MVP Playbook

Here are the core principles — distilled.

1️⃣ Start from the problem, not the solution

An MVP is not a product idea.

It’s a problem validation tool.

Before building anything, make sure:

• the problem is real

• it’s painful

• it happens frequently

• users actively want a solution

Use:

• user interviews

• manual workflows

• landing pages

• surveys

No strong problem → no meaningful MVP.

2️⃣ Define a clear hypothesis

Every MVP should be driven by a simple statement:

“We believe that [user] has [problem], and that [solution] will solve it.”

This is your decision filter.

If a feature doesn’t validate the hypothesis → it’s out.

3️⃣ Identify and protect the core feature

Your MVP has one job:

👉 deliver the smallest possible version of the core value

The core feature is:

• the main user action

• the moment where value is experienced

Everything else is secondary.

4️⃣ Cut scope aggressively (not quality)

This is one of the most important lessons.

When under pressure:

❌ Don’t cut tests

❌ Don’t cut structure

❌ Don’t introduce shortcuts

✅ Cut features

✅ Simplify flows

✅ reduce variability

Scope is flexible. Quality is not.

5️⃣ Work in thin vertical slices

Avoid building layers (frontend, backend, infra) separately.

Instead, build end-to-end slices:

• minimal UI

• minimal logic

• minimal data

• deployed and usable

If it doesn’t work in production, it doesn’t generate learning.

6️⃣ Make everything testable

Testability is what keeps your MVP maintainable over time.

Key practices:

• automated tests (non-negotiable)

• small, focused components

• clear boundaries

Even in an AI-driven future:

Tests are the only way to ensure your system behaves as expected.

7️⃣ Use TDD to control complexity

Test-Driven Development helps you:

• avoid overengineering

• implement only what’s needed

• keep design simple

It naturally supports incremental development.

8️⃣ Set up CI/CD from day one

To stay fast over time:

• run tests on every change (CI)

• keep the system always deployable (CD)

• release frequently

This gives you:

• fast feedback

• safer changes

• continuous validation

9️⃣ Build an architecture that can evolve

Start with a walking skeleton:

• one repo

• one pipeline

• one working slice

• minimal abstractions

Then evolve only when needed:

• add a database later

• split services later

• scale infrastructure later

Architecture should grow with the product — not before it.

🔟 Keep technical debt intentional

Not all debt is bad.

But you must distinguish:

• intentional debt → visible, temporary, manageable

• accidental debt → hidden, risky, expensive

Technical debt is not just code:

• architecture complexity

• unclear domain understanding

• unnecessary features

Your goal is not zero debt.

👉 It’s controlled debt.

1️⃣1️⃣ Bring users in early

The MVP is useless without real users.

Involve them through:

• alpha programs

• beta testing

• user interviews

• in-app feedback

• NPS surveys

Focus on:

• early adopters

• champion users

Users don’t just validate your product — they shape it.

1️⃣2️⃣ Keep feedback loops short

Speed is not about writing code faster.

It’s about learning faster.

To do that:

• release frequently

• measure behavior

• talk to users

• adapt continuously

Long cycles = slow learning = wasted effort.

1️⃣3️⃣ Prefer simplicity over flexibility

Early systems don’t need to be flexible.

They need to be:

• understandable

• modifiable

• testable

Avoid:

• overengineering

• premature abstractions

• unnecessary configuration

You can always add flexibility later.

1️⃣4️⃣ Combine product, tech, and user thinking

A successful MVP sits at the intersection of:

• Product → solving the right problem

• Technology → enabling fast and safe changes

• Users → validating real value

Ignoring one of these creates imbalance.

⚖️ The Big Trade-off

At every step, you’re balancing:

• speed today

• speed tomorrow

Bad MVPs optimize only for today.

Good MVPs optimize for both.

And the key principle is always the same:

Reduce scope to go fast — never reduce quality.

🚀 How to Use This Playbook

Before starting your next MVP, go through this checklist:

• Do we have a clear problem and hypothesis?

• Are we building only the core feature?

• Are we working in thin slices?

• Do we have tests and CI/CD in place?

• Is our architecture minimal and evolvable?

• Are we involving real users early?

• Are we learning fast enough?

If the answer is yes to all of these:

👉 you’re not just building fast

👉 you’re building sustainably fast

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

1️⃣2️⃣ Chapter 12 – Release in slices

1️⃣3️⃣ Chapter 13 – TDD from day one

1️⃣4️⃣ Chapter 14 – Thin slices for testable software

1️⃣5️⃣ Chapter 15 – Bring the first users early

1️⃣6️⃣ Chapter 16 – Managing Technical Debt from Day One → You’re here.

1️⃣7️⃣ Chapter 17 – Best practices for building an MVP → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You’re building your MVP.

Time is tight.

Pressure is high.

Decisions are made quickly.

And at some point, someone says:

“Let’s do it quickly now, we’ll fix it later.”

That’s the moment technical debt is born.

Not months later.

Not at scale.

Right there.

Early shortcuts feel harmless:

• skipping tests

• hardcoding logic

• duplicating code “just for now”

• ignoring edge cases

• delaying refactoring

The problem is not the shortcut itself.

The problem is that shortcuts accumulate silently.

Weeks later:

• changes become harder

• bugs become more frequent

• releases become slower

• confidence drops

And suddenly the team says:

“We need to refactor everything.”

But by then, it’s already expensive.

⚡ What Technical Debt Really Is

The term “technical debt” was introduced to describe the trade-off between quick delivery and long-term maintainability.

But it’s often misunderstood.

Technical debt is not just bad code.

It includes:

• code debt → duplication, poor structure, lack of tests

• architecture debt → rigid or overcomplicated design

• domain debt → misunderstanding the business problem

• product debt → building unnecessary or misaligned features

In short:

Technical debt is unmanaged complexity.

And complexity grows non-linearly.

At the beginning, it feels manageable.

Then it slows you down.

Then it blocks you.

And the most dangerous type is:

👉 unexpected technical debt

The kind you didn’t plan, didn’t track, and can’t easily fix.

⚡ Why This Matters

You can’t avoid all debt.

In fact, some debt is necessary.

• You don’t know everything at the start

• Requirements evolve

• Trade-offs are inevitable

This is intentional debt — and it can be managed.

The real problem is accidental debt:

• introduced without awareness

• discovered too late

• expensive to fix

This is what kills velocity.

And here’s the key insight:

Most accidental debt comes from cutting quality instead of cutting scope.

🛠 How We Solve It

If you want to move fast without slowing down later, the rule is simple:

👉 Reduce scope. Never reduce quality.

Let’s make it concrete.

1️⃣ Scope Is the Only Safe Lever

When under pressure, teams often choose between:

• delivering less

• or delivering lower quality

The correct choice is almost always:

👉 deliver less

Examples:

• instead of full permissions → start with 2 roles

• instead of full analytics → one key metric

• instead of flexible workflows → one fixed flow

Scope reduction keeps:

• code simple

• tests manageable

• feedback fast

Cutting quality does the opposite.

2️⃣ Automated Tests Are Non-Negotiable

Without automated tests:

• you don’t know if changes break existing behavior

• refactoring becomes risky

• bugs accumulate silently

With automated tests:

• you get fast feedback

• you can refactor safely

• you can evolve the system

This is why testability is the foundation of maintainability.

Even in a future where AI writes most of the code:

👉 tests are the only reliable verification mechanism

No test suite = no safety net.

3️⃣ TDD Prevents Overengineering

Test-Driven Development forces you to:

• implement only what is needed

• keep functions small

• design for testability

It naturally limits complexity.

Instead of designing everything upfront, you grow the system incrementally.

This reduces both:

• overengineering

• unnecessary features

4️⃣ Continuous Integration Prevents Drift

Without CI:

• code diverges

• integration becomes painful

• bugs appear late

With CI:

• changes are integrated constantly

• problems are detected early

• complexity stays visible

CI doesn’t eliminate debt.

But it prevents it from hiding.

5️⃣ Continuous Delivery Keeps the System Honest

If your system is always deployable:

• infrastructure stays simple

• deployment stays predictable

• releases stay small

If you delay releases:

• complexity accumulates

• assumptions go unvalidated

• risk increases

CD forces continuous validation.

6️⃣ Keep Complexity Visible and Intentional

Some debt is acceptable — if it’s:

• visible

• documented

• temporary

Examples:

• quick implementation to validate a hypothesis

• simplified logic to test a feature

• temporary duplication before refactoring

The key is:

👉 you know it exists, and you plan to address it

Unmanaged debt is the problem — not debt itself.

⚖️ Trade-offs

Maintaining high quality from day one requires:

• writing tests

• setting up CI/CD

• thinking in smaller increments

• resisting shortcuts

But the alternative is:

• slow delivery after initial speed

• fragile code

• expensive rewrites

• lost trust in the system

Short-term shortcuts create long-term friction.

🚀 Next Steps (Tomorrow Morning)

when working your next MVP or Feature MVP, ask:

• Are we reducing scope — or cutting quality?

• Are we skipping tests to go faster?

• Is this complexity intentional or accidental?

Then:

1. Identify one feature that feels too big → reduce its scope

2. Add tests for one critical part → increase safety

3. Ensure your pipeline runs on every commit → increase visibility

Small actions compound.

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

1️⃣2️⃣ Chapter 12 – Release in slices

1️⃣3️⃣ Chapter 13 – TDD from day one

1️⃣4️⃣ Chapter 14 – Thin slices for testable software

1️⃣5️⃣ Chapter 15 – Bring the first users early → You’re here.

1️⃣6️⃣ Chapter 16 – Tech trade-offs: simple now vs debt later → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You built the walking skeleton.

You added the first slices of functionality.

The system runs in production.

But only the team is using it.

This is one of the most common traps in early product development: teams spend months building before real users ever touch the product.

When the first users finally arrive, surprises happen:

• the workflow doesn’t match how people actually work

• the onboarding is confusing

• the “core feature” isn’t the real problem users care about

• users behave in ways nobody expected

At this point the team discovers something uncomfortable:

Most of the decisions were made without real users.

Lean product development was designed to avoid exactly this problem.

The Lean Startup methodology emphasizes involving users as early as possible and iterating based on real feedback rather than assumptions.

The earlier real users interact with your product, the faster you learn whether you’re building the right thing.

⚡ Why It Matters

Getting early users involved is not just about feedback.

It changes the entire development dynamic.

1. Real usage validates assumptions

Internal testing cannot simulate real behavior.

Real users:

• misunderstand interfaces

• use features in unexpected ways

• find shortcuts you never predicted

• ignore features you thought were essential

That information is priceless.

2. Early adopters drive product adoption

Products rarely spread evenly across users.

They follow the technology adoption curve:

• Innovators

• Early adopters

• Early majority

• Late majority

• Laggards

Your MVP is not for everyone.

It’s for innovators and early adopters.

These users tolerate rough edges and actively want to influence the product.

3. Early feedback accelerates product-market fit

Customer feedback is one of the most important drivers of MVP iteration because it helps validate assumptions and identify what users actually need.

Without feedback, teams iterate blindly.

With feedback, each iteration becomes a learning experiment.

4. Adoption starts during onboarding

Adoption is not just about sign-ups — it’s when users start deriving real value from the product and integrate it into their workflow.

Early onboarding experiences determine whether users reach that value moment quickly or abandon the product.

🛠 How We Solve It

Here are practical ways to bring users into the life of your product early.

1️⃣ Launch an Alpha Program

Alpha users are the first real users who interact with the product.

Characteristics of alpha users:

• often internal users or trusted partners

• high tolerance for bugs

• willing to give detailed feedback

• understand they are testing something unfinished

The goal of alpha testing is not scale.

It is learning fast.

Typical alpha sources:

• internal teams

• friendly companies

• developer communities

• personal network

At this stage, direct communication with users is often more valuable than analytics.

2️⃣ Run a Structured Beta Program

A beta program expands testing to external users before a full launch.

Beta programs allow you to evaluate the product in real-world conditions and gather insights for improvement.

Typical beta program practices:

• invite a limited group of users

• communicate that the product is experimental

• provide a feedback channel

• iterate frequently based on feedback

The best beta programs treat participants as collaborators.

They are not just users.

They are product partners.

3️⃣ Identify Champion Users

Among early users, some people naturally become advocates.

These champion users:

• use the product frequently

• provide detailed feedback

• suggest improvements

• promote the product internally

Champion users are incredibly valuable.

They help you understand:

• real workflows

• high-value features

• adoption barriers

Many successful products grow through these champions.

4️⃣ Run Continuous User Interviews

User interviews remain one of the most powerful learning tools.

Best practices:

• talk to users regularly

• focus on their problems, not your features

• observe real usage when possible

• document insights and patterns

Interviews complement analytics by revealing the why behind behavior.

5️⃣ Measure Feedback with NPS and Surveys

Quantitative feedback helps identify trends.

Common techniques include:

• NPS surveys

• in-app feedback forms

• short usability surveys

• onboarding questionnaires

In-app surveys are widely used during beta testing to validate ideas and prioritize improvements.

NPS is particularly useful for identifying promoters who may become champion users.

6️⃣ Build Feedback Channels into the Product

The easiest way to collect feedback is directly inside the app.

Examples:

• “Send feedback” button

• bug report form

• quick surveys

• feature request widgets

This allows users to provide feedback in context, when the experience is fresh.

7️⃣ Combine Online and Offline Feedback

Not all feedback needs to happen inside the app.

Offline channels are often more valuable in early stages:

• Slack communities

• private Discord groups

• email feedback loops

• live user calls

• product demos with discussion

Early-stage products benefit enormously from high-touch communication.

⚖️ Trade-offs

Early user involvement comes with trade-offs.

You may expose:

• unfinished features

• imperfect UX

• occasional bugs

But the alternative is worse:

• building features nobody uses

• discovering problems too late

• launching a product nobody understands

Early feedback reduces uncertainty — which is the most expensive problem in product development.

🚀 Next Steps (Tomorrow Morning)

If your MVP is already running:

1. Identify 5–10 early adopters who might benefit from your product.

2. Invite them into an informal alpha program.

3. Schedule short user interviews after their first usage.

4. Add a feedback button or survey inside the product.

The goal is not perfection.

The goal is learning faster than everyone else.

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

1️⃣2️⃣ Chapter 12 – Release in slices

1️⃣3️⃣ Chapter 13 – TDD from day one

1️⃣4️⃣ Chapter 14 – Thin slices for testable software → You’re here.

1️⃣5️⃣ Chapter 15 – Bring the first users early → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You start implementing a feature. It seems simple at first, especially in a fresh project.

Then it grows.

The feature touches the UI, business logic, database, API integration, and maybe authentication. Tests become harder to write. The feature branch gets larger. Integration takes longer.

Eventually someone says:

“We’ll add tests later.”

Looks reasonable, right? We need to go to the market as quickly as possible.

But “later” rarely comes.

The problem isn’t laziness or lack of discipline.

The real problem is that the feature was never designed to be testable.

Large features are hard to test, and even harder to add test after.

And when features are hard to test:

• tests are skipped

• regressions increase

• refactoring becomes risky

• the codebase slowly becomes fragile

This is exactly why thin slices are essential.

Thin slices are not only a delivery technique.

They are a testability strategy.

⚡ Why It Matters

Kent Beck, the creator of Extreme Programming and Test-Driven Development, repeatedly emphasized that testability is the fundamental enabler of change.

Software that cannot be tested cheaply cannot evolve.

Martin Fowler makes a similar point: the real value of automated tests is not catching bugs — it is enabling safe refactoring and continuous change.

This becomes even more important when we consider modern development trends.

Even if AI generates large portions of code in the future, one thing remains true:

Automated tests are the only scalable way to ensure software does what you expect.

Human review does not scale.

Manual testing does not scale.

Documentation does not scale.

Only automated verification scales with complexity.

Thin slices make this possible.

⚡ Thin Slices Make Testing Cheap

When features are sliced properly:

• each increment changes only a small part of the system

• the behavior under test is clear

• tests are simple to write

• failures are easy to diagnose

Small slices reduce the cost of testing dramatically.

This is why many modern engineering practices converge around the same idea:

• TDD encourages tiny increments

• Continuous Integration encourages frequent integration

• Continuous Delivery encourages small releases

• Feature slicing encourages minimal behavioral changes

All these practices reinforce each other.

🛠 How We Solve It

Let’s explore practical techniques for building thin slices that are easy to test.

1️⃣ Slice by Behavior, Not by Layer

A common mistake is slicing features by technical layers.

Example:

• Backend API first

• Database schema later

• UI last

This creates large integration points.

Instead, slice by user behavior.

Example:

First slice:

• user can create a simple item

• minimal API

• minimal database structure

• minimal UI

Second slice:

• user can edit the item

Third slice:

• user can delete the item

Each slice is:

• end-to-end

• small

• testable

And each slice adds a small, verifiable behavior.

2️⃣ Write Tests Close to the Behavior

Martin Fowler often describes the Test Pyramid:

• many fast unit tests

• fewer integration tests

• very few end-to-end tests

Thin slices help maintain this structure.

If a slice introduces only a small behavior change:

• unit tests verify the logic

• integration tests verify collaboration

• end-to-end tests confirm user flow

Large features tend to push teams toward expensive end-to-end tests.

Small slices keep most tests cheap.

3️⃣ Use TDD to Enforce Small Increments

Test-Driven Development naturally pushes developers toward thin slices.

The TDD loop is simple:

1. write a failing test

2. write minimal code to pass

3. refactor

4. repeat

Because tests are written first, developers avoid building large speculative features.

Instead they grow functionality step by step.

This aligns perfectly with MVP development.

4️⃣ Keep Tests Fast and Focused

Kent Beck emphasized that fast feedback loops are essential.

If tests take minutes to run, developers run them less frequently.

Thin slices help keep tests fast because:

• fewer components change

• fewer integration points are involved

• failures are localized

Fast tests encourage frequent execution, which strengthens CI pipelines.

5️⃣ Protect Testability with Good Architecture

Testability doesn’t happen by accident.

Architectural patterns like:

• Hexagonal Architecture

• Clean Architecture

• Ports and Adapters

separate business logic from infrastructure.

This separation allows:

• testing business logic without external systems

• mocking infrastructure dependencies

• writing fast unit tests

Architecture and thin slicing reinforce each other.

⚖️ Trade-offs

Thin slicing requires discipline.

It often means:

• thinking harder before coding

• splitting work more carefully

• resisting the urge to build everything at once

But the alternative is worse:

• complex tests

• slow pipelines

• fragile code

• risky refactoring

Thin slices trade a little design effort for long-term maintainability.

🚀 Next Steps (Tomorrow Morning)

Pick a feature currently in progress.

Ask yourself:

• Can this be split into two smaller behaviors?

• Can each behavior be tested independently?

• Can each slice be integrated today?

If the answer is no, the feature is probably too big.

Slice it again.

The easiest software to test is software built in tiny increments.

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

1️⃣2️⃣ Chapter 12 – Release in slices

1️⃣3️⃣ Chapter 13 – TDD from day one → You’re here.

1️⃣4️⃣ Chapter 14 – Build testable features → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You’re building the first real features after the walking skeleton.

Pressure is high.

Stakeholders want progress.

The market is moving.

And someone inevitably says:

“We don’t have time for TDD.”

“Let’s skip tests for now.”

“We’ll clean it up later.”

This is where most MVPs begin accumulating invisible debt.

The reasoning sounds logical:

“We need speed. Discipline can come later.”

But research tells a different story.

According to Pendo’s Product Benchmarks Report, around 80% of features in software products are rarely or never used.

That means the biggest waste in software is not writing tests.

It’s building things that don’t create value.

The second major source of waste?

Unplanned work — bugs, regressions, unexpected behaviors, firefighting.

And what creates unplanned work?

• Large batches

• Untested changes

• Fragile integration

• Manual deployments

• Poor feedback loops

So here’s the uncomfortable truth:

Cutting engineering discipline does not make you faster.

It just delays the bill.

⚡ Why It Matters

There are two kinds of speed:

1. Apparent speed – You ship something quickly.

2. Sustainable speed – You keep shipping quickly.

Most teams optimize for the first and destroy the second.

If 80% of features are unused, the only rational strategy is:

• Build less.

• Validate earlier.

• Keep change cheap.

And this is true especially in the early days, when you don’t know if a feature will fall into the 80% or 20% and you need to build a lot of different features to know it.

Therefore, we want change to remain cheap - and change is cheap only when:

• Code is covered by tests.

• Integration happens continuously.

• Deployment is automated.

• Releases are small and reversible.

TDD, CI and CD are not “enterprise practices.”

They are anti-waste mechanisms.

They protect you from:

• Building too much.

• Breaking too much.

• Reworking too much.

And the fastest way to go fast?

Reduce scope, keep things as simple as possible, have automated tests to ensure your changes are correct.

Build the MVP of a feature — not the full version.

🛠 How We Solve It

Let’s make this practical.

1️⃣ Reduce Scope, Not Quality

If a feature feels too big, don’t remove tests.

Remove functionalities or simplify them.

Instead of:

• Full role management system → start with 2 roles.

• Complex reporting dashboard → start with one core metric.

• Configurable workflows → start with one fixed flow.

• Users can ask for a custom configuration → start with an email or slack notification.

Scope is the lever.

Quality is not negotiable.

2️⃣ Use TDD to Force Simplicity

Test-Driven Development naturally encourages:

• Small increments.

• Clear interfaces.

• Minimal implementation.

• Refactoring confidence.

TDD prevents speculative design because you only implement what is required to pass the test.

It aligns perfectly with MVP thinking:

• Write a failing test for the smallest valuable behavior.

• Make it pass.

• Refactor.

• Repeat.

The result?

No overengineering.

No invisible assumptions.

No accidental complexity.

3️⃣ Continuous Integration from Day One

CI means:

• Integrate to main multiple times per day.

• Keep the build green.

• Run all tests automatically.

• Make integration boring.

CI reduces unplanned work because:

• Integration issues are discovered immediately.

• Merge conflicts stay small.

• Architectural drift is visible early.

Large feature branches are delayed feedback.

Delayed feedback is waste.

4️⃣ Continuous Delivery to Keep Learning Fast

CD means your software is always deployable.

Even if you don’t release to customers daily, you should be able to.

Benefits:

• Infrastructure stays validated.

• Deployment risk stays low.

• You can release small experiments quickly.

• You can rollback easily.

Deployment becomes routine instead of an event.

5️⃣ Why This Minimizes Waste

Let’s connect the dots:

Waste #1: Unused Features

TDD + Small slices →

You build only what is explicitly needed.

CI + Small releases →

You get feedback sooner and stop building sooner.

CD →

You validate assumptions in production faster.

Waste #2: Unplanned Work (Bugs, Regressions)

TDD →

Fewer regressions.

CI →

Early integration problems.

CD →

Deployment issues surface early, not months later.

The faster you close feedback loops, the less unplanned chaos you create.

⚖️ Trade-offs

Yes, writing tests takes time.

Yes, setting up CI/CD requires initial effort.

Yes, slicing features is harder than building the whole thing.

But compare that to:

• Weeks lost fixing regressions.

• Rewriting unused features.

• Fighting merge conflicts.

• Delayed releases due to fragile deploys.

Short-term discipline prevents long-term drag.

You are investing 1$ more today to avoid a 10$ loss tomorrow.

🚀 Next Steps (Tomorrow Morning)

If you’re starting a new feature:

1. Write one test for the smallest valuable behavior.

2. Integrate the change the same day.

3. Ensure the pipeline runs automatically on every commit.

4. Ask: “What is the MVP of this feature?”

If it feels slow, reduce scope further.

Remember:

You don’t go fast by cutting quality.

You go fast by simplifying and reducing what you build.

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

1️⃣2️⃣ Chapter 12 – Release in slices → You’re here.

1️⃣3️⃣ Chapter 13 – TDD from day one → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You’ve got your walking skeleton deployed — congratulations. Now it’s time to add features. But here comes a familiar problem:

Teams plan features as big chunks, work for weeks, then merge everything all at once. A single merge request becomes a mountain of changes. Stakeholders and users only see something meaningful after long waits. When feedback finally arrives, it often invalidates most of what was built.

This pattern — batching large chunks of work — slows everything down:

• Integration conflicts linger until the end

• Feedback loops are long and weak

• Risk accumulates and surprises blow up late

• Your MVP turns into a “MVP-ish” project that never validates anything

The antidote is simple (in principle, not always in practice): release in the smallest valuable slices possible, as early and often as you can.

Agile and DevOps wisdom has long championed this approach — delivering small increments, integrating constantly, and gathering feedback early. Releasing in slices isn’t just about features; it’s about keeping the product and the team aligned with real value delivery.

⚡ Why It Matters

Small releases accelerate learning.

Delivering in small slices shortens feedback loops with stakeholders, internal users, and real customers. Short cycles uncover wrong assumptions early, when change is cheap.

Small releases reduce risk.

Tiny changes mean smaller blast radius when something breaks. You can pinpoint issues faster and roll back or fix quickly.

Small releases keep the codebase healthy.

Large batches hide latent code that isn’t tested in context until it’s “finished”. This delays integration feedback and harms quality over time.

Small releases support better architecture.

Frequent integration supports evolutionary design, prevents brittle structures, and surfaces architectural issues early.

The bottom line: big batches are expensive, slow, and high-risk. Small increments create a feedback-rich loop that is the core of continuous delivery and learning.

🛠 How We Solve It: Practices to Release in Slices

Here are the tools and techniques that enable tiny releases and continuous delivery of value.

1. Continuous Integration (CI) — The Essential Practice

CI is the heart of releasing in slices: integrate changes into a shared codebase as soon as there is forward progress and the build is healthy.

Key principles of CI include:

• Maintain a single code repository

• Automate the build

• Run automated tests on every commit

• Keep tests fast and reliable

• Integrate changes frequently (multiple times a day)

• Make build results visible to everyone

CI forces integration early and often — this means small changes land quickly, and feedback arrives before large conflicts accumulate.

If your current workflow waits for a long-lived feature branch to merge at the end, it’s not Continuous Integration. It’s integration late, and it hides problems until the last moment.

2. Slice Features Vertically

To release small increments that deliver value, you must slice vertically — not by technical layers.

Instead of splitting by “backend first / frontend later,” slice this way:

• “User can do one small thing end-to-end”

• Then add another tiny thing

• Then another

• … until each slice is usable, testable, and releasable

The Elephant Carpaccio exercise (by Alistair Cockburn) is a great workshop for practicing this: slice work so thinly that each piece creates value and can be released independently.

Vertical slices let you gather real feedback instead of waiting until all layers are done.

3. Release Unfinished Work Safely

With CI and slicing, you often land code that is not yet revealed to users — and that’s okay if you use techniques that keep it invisible until ready.

Feature Flags (Feature Toggles)

Feature flags let you merge in incomplete features and keep them disabled by default. The code is deployed, tested, and integrated, but it doesn’t affect user experience until you flip the switch.

Feature flags allow:

• Controlled releases (test with a small group first)

• A/B testing

• Dark launches (see performance effects before exposing users)

• Decoupling deployment from release 💡

Flags should be removed once the feature is fully released — leaving no “toggle debt” behind.

4. Keystone Interfaces & Latent Code

Martin Fowler describes the idea of latent code — code that is present in a release but not yet visible to users. A keystone interface ensures that code is not executed in production until it’s truly ready, while higher-level tests exercise it behind the scenes.

This lets you:

• Integrate unfinished functionality early

• Test it with CI pipelines

• Keep production behavior stable

• Enable it progressively with minimal risk

5. Branch By Abstraction for Big Changes

When you face large infrastructure or platform changes (e.g., migration to a new data store), branch by abstraction lets you evolve the codebase step by step without blocking releases.

You create an abstraction layer that supports both old and new implementations, gradually moving clients over to the new version while keeping the system releasable at all times. This supports both CI and incremental release.

6. Break Large Changes into Reversible Steps

Complex structural or schema changes (like renaming a database field) should be broken into reversible steps (expand–contract strategy):

1. Add new field

2. Write to old + new

3. Copy data

4. Switch reads to new

5. Remove old

Each step can be reversed independently — making releases safe and undoable if something goes wrong.

7. Keep Feedback Loops Tight

Frequent releases invite feedback not just from automated tests but from real people. Internal users, customer beta programs, feedback tools, analytics — they provide data early that informs priorities.

The agile mantra of “inspect and adapt” depends on rapid feedback — and rapid release is the only way to get it.

⚖️ Trade-offs

Releasing in small slices and using CI isn’t free:

• You invest in test automation early

• You must manage feature flags and remove them promptly

• Teams need discipline to slice, integrate, and deploy frequently

• You may expose latent code in production — but safely controlled

However, these costs pay off in:

• Less risk

• Better quality

• Faster learning

• Fewer late-stage surprises

Small slices keep complexity from compounding — instead of big batches compounding risk.

🚀 Next Steps (Tomorrow Morning)

1. Make sure your CI pipeline runs on every commit and keeps the build green.

2. Practice slicing one current feature into vertical, releasable pieces.

3. Introduce feature flags for any incomplete functionality that must be deployed early.

4. Plan at least one WIP hidden release to test impact before wide release.

Release something, no matter how small — the sooner you do, the sooner you learn.

Reply to this email if you are curious about anything in this issue — I will be happy to reply to your questions directly! :)

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First

1️⃣1️⃣ Chapter 11 – An architecture that can evolve → You’re here.

1️⃣2️⃣ Chapter 12 – Release in slices → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You deployed your walking skeleton — minimal frontend, a basic API, simple database connection — and it’s running in production.

But then new features creep in, deadlines loom, teams grow, and suddenly architecture questions that once felt “future-y” become blockers:

• Where should new services live?

• Is the database schema flexible enough?

• How do we ensure deploys stay reliable with more components?

• How do we measure whether architecture quality is improving or deteriorating?

Left unchecked, these questions morph into design debt — hidden complexity, fragile builds, unpredictable releases, and last-minute rewrites. That’s not accidental. It’s what happens when architecture is treated as a “phase” rather than a living part of development.

With modern Teams and products evolving fast, architecture must evolve with them — in production, incrementally, guided by real feedback. This is what industry leaders call evolutionary architecture.

⚡ Why It Matters

Evolutionary architecture is not about building a perfect system up front. It’s about making guided change a first principle.

Here’s why:

1. Changes Are the Norm, Not the Exception

Business needs shift, learnings arise from real usage, and new constraints surface. A static architecture will break or be abandoned.

2. Incremental Design Reduces Risk

By incorporating architectural practices into daily work, you avoid huge redesigns later. Small architectural improvements made with confidence beat big risky refactors.

3. Architecture Must Be Validated in Production

If your only production code is the walking skeleton, until that point architecture was just hopeful design. In evolutionary architecture, every commit is a test of your assumptions.

4. Continuous delivery is the foundation of evolution

Martin Fowler highlights that continuous delivery — making software deployable at any time — is essential to architecture that evolves. A deployment pipeline lets you test architectural assumptions automatically.

5. Fitness Functions Quantify Architectural Qualities

Instead of relying on human memory or opinion, fitness functions are automated checks that measure architectural health (e.g., dependency rules, performance budgets, resilience). They let you define “architectural success” and enforce it.

🛠 How We Solve It: Practices That Enable Evolution

Below are practical techniques and tools that support evolutionary architecture — both for infrastructure and for software structure.

1. Infrastructure as Code (IaC)

Your infrastructure should be versioned, automated, and testable just like application code.

Tools like Terraform, Pulumi, and AWS CDK let you declare infrastructure in code, so:

• Environments are reproducible

• Changes are trackable

• Rollbacks are possible

• Drift is detectable

IaC transforms provisioning from a manual ritual to a refinable, evolvable asset.

The practice of managing cloud infrastructure via code codifies familiar engineering benefits: version control, code review, rollback, and automation.

2. Deployment Pipelines That Include Architectural Checks

Continuous Delivery pipelines are more than “automatic deploy” screens — they are the engines of architectural validation.

Key elements:

• Unit & Integration Tests — catch errors early

• Contract and API Tests — ensure endpoints maintain compatibility

• Architectural Fitness Tests — automated checks for structural constraints (dependency rules, layering, code complexity thresholds)

• Database Migration Checks — ensure schema changes are safe

• Env Validation — smoke tests in a staging that mirrors production

These checks ensure that every change not only works but preserves architectural health.

3. Software Architecture Patterns for Change

Great architecture designs don’t force future choices — they encapsulate change.

Clean / Onion / Hexagonal Architecture

Patterns like Clean, Onion, or Hexagonal (Ports & Adapters) isolate domain logic from infrastructure and external integrations, making them replaceable and testable.

Benefits:

• Business logic sits at the core

• Adapters (UI, DB, external services) plug in around the core

• Tests can target core logic independently

• Infrastructure changes have minimal ripple effects

• Refactoring becomes safer and frequent

This structure aligns beautifully with evolving MVP codebases.

4. Refactoring and Emergent Design

Kent Beck, an early proponent of evolutionary practices through Extreme Programming (XP), emphasised emergent design — design that grows as needed, not all up front.

With emergent design:

• You extend architecture only in response to real needs

• Refactoring is the engine that keeps the codebase healthy

• Over-engineering is replaced by just enough architecture

This approach assumes architecture will grow — and plans for it.

5. Fitness Functions: Architecture Tests You Can Automate

A fitness function is an automated measure of how well a system aligns with architectural goals. They can evaluate:

• Coupling and dependency constraints

• API compatibility and contract stability

• Performance thresholds

• Security policies

• Chaos and resiliency checks (load, fault injection)

Automating these ensures architectural qualities don’t degrade unnoticed.

6. Continuous Delivery as an Architectural Enabler

Martin Fowler defines Continuous Delivery as the discipline that keeps software deployable at any point in time.

This discipline:

• Ensures architectural assumptions are exercised often

• Pushes teams to build testable, modular code

• Makes production deployments routine, so evolution happens in practice

⚖️ Trade-offs

Evolving architecture is powerful — but not free:

• Early automation requires effort, but saves rewrites later

• Fitness functions must be chosen carefully — too many checks can slow pipelines

• Patterns like hexagonal/clean add structure — but demand discipline initially

• Refactoring must be continuous — and that requires team investment

The trade-off is always: pay a little early to avoid paying a lot late — and in MVP contexts, this is especially true.

🚀 Next Steps (Tomorrow Morning)

If your MVP is now running and you want architecture that can evolve:

1. Formalise your infrastructure in code (Terraform/Pulumi/CDK).

2. Integrate at least one architectural fitness function into your pipeline (e.g., dependency rule, performance smoke test).

3. Refactor one component toward clean/hexagonal structure — isolate domain logic from adapters.

These steps help ensure your MVP isn’t just deployed — it’s buildable, evolvable, and resilient.

Any question about evolutionary architectures techniques and technologies?

Reply to this email — I’ll help you stress-test it with a simple walking skeleton example on LinkedIn.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

⏩ Section 2 - Building the MVP

1️⃣0️⃣ Chapter 10 – Get to Production First → You’re here.

1️⃣1️⃣ Chapter 11 – An architecture that can evolve

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

👋 Welcome back (2026 edition)

Happy new year, and welcome back to AgileBits.

With this issue we start a new section of the Practical Handbook for Product Developers: Building the MVP.

In the previous section (First Steps: Idea, Validation, MVP), we focused on what to build and why: problem validation, scope, prioritisation, and product mindset.

From now on, we’ll focus on how to build an MVP in practice — day by day, release by release — without falling into over-engineering or local-only development traps.

And we start with the most important principle of all.

🔎 Scenario / Pain Point

Many teams start building an MVP by working locally for weeks — sometimes months.

They design architecture diagrams, define modules, add abstractions, and keep piling up features. Everything works fine on their laptops. Tests pass. Demos look great.

Then, close to the “launch”, reality hits:

• Deployment is complex and fragile

• Infrastructure assumptions don’t hold

• Environment differences break things

• Authentication, networking, secrets, permissions were “postponed”

• Architectural decisions made months ago are hard to revisit

• Nobody clearly remembers why certain choices were made

The real problem here is not technical skill: is timing.

Architecture, infrastructure, and delivery decisions were made without being validated in production. And production is where systems actually exist.

This is exactly what the walking skeleton is meant to prevent.

⚡ Why It Matters

An MVP is not real until it runs in production.

A walking skeleton is the smallest possible system that:

• Runs end-to-end

• Is deployable automatically

• Touches all major architectural components

• Can evolve incrementally

Starting from a walking skeleton matters because:

1. Architecture must be validated, not imagined

Architectural choices are hypotheses.

If they are not exercised in production early, you are just guessing.

2. Production feedback is different from local feedback

Latency, configuration, secrets, permissions, build pipelines — none of these behave like local environments.

3. Early deployment reduces cognitive load

Shipping small pieces frequently keeps decisions fresh.

You don’t “rediscover” complexity months later.

4. Evolutionary architecture requires evolution points

Architecture that evolves needs real release cycles.

Without production releases, nothing evolves — it just accumulates.

5. The cost of change is lowest at the beginning

Fixing a bad assumption after one week is cheap.

Fixing it after three months is painful — or impossible.

🛠 How We Solve It: Build a Walking Skeleton

A walking skeleton is not a feature.

It’s a delivery-first strategy.

Here’s a practical way to approach it.

1. Start with deployment, not features

Before building “real functionality”, answer one question:

Can we deploy something, end-to-end, to production?

If your system has frontend and backend, treat them independently — but deploy both.

Example:

• Frontend: a minimal “Hello World” page

• Backend: a minimal “Hello World” API

• CI pipeline: build → test → deploy

• Infrastructure: minimal, boring, explicit

No business logic yet.

No users yet.

Just a system that exists in production.

2. Grow the skeleton one slice at a time

Once the skeleton is alive, evolve it incrementally.

Backend example:

1. Deploy a basic API

2. Add a database

3. Deploy again

4. Add one endpoint that reads real data

5. Deploy again

6. Add authentication

7. Deploy again

8. Add a sample test

9. Add test execution to pipeline

10. Deploy again

Frontend example:

1. Deploy static UI

2. Call the real API

3. Render real data

4. Handle loading/errors

5. Deploy each step

6. Add a sample test

7. Add test execution to pipeline

8. Deploy again

Each step:

• Small

• Reversible

• Validated in production

No big-bang releases.

3. Treat infrastructure as part of the MVP

Infrastructure is not “later work”.

In an MVP:

• CI/CD is part of the product

• Deployment scripts are part of the product

• Environment configuration is part of the product

A walking skeleton ensures infrastructure evolves with features, not against them.

4. Let architecture emerge from real needs

Don’t design for scale you don’t have.

Instead:

• Start with the simplest structure that works

• Add boundaries only when pressure appears

• Refactor when reality forces your hand

This is evolutionary architecture in practice:

• Architecture grows as the system grows

• Decisions are driven by usage, not fear

• Complexity is earned, not assumed

5. Release continuously, even when it feels “too small”

Releasing a “tiny change” is not wasteful.

Not releasing is.

Every release:

• Validates assumptions

• Exercises the pipeline

• Keeps the system honest

• Builds confidence in delivery

If you can’t release today, you’re already late.

⚖️ Trade-offs

• Early releases expose rough edges — but hide nothing

• A walking skeleton may feel “slow” initially — but prevents massive rework

• Minimal infrastructure feels naive — until it saves you weeks later

• Frequent deployments require discipline — but reduce risk

• You may throw code away — but you avoid throwing the whole system away

This is a conscious trade:

short-term discomfort for long-term speed.

🚀 Next Steps (Tomorrow Morning)

If you’re starting an MVP — or already building one:

1. Ask: Can we deploy something end-to-end today?

   If not, stop adding features and fix that first.

2. Create a minimal CI/CD pipeline for frontend and backend, even if the app does nothing useful yet.

3. Plan your next features as production-ready thin slices, not local-only chunks.

4. Treat every architectural decision as provisional until exercised in production.

Which architectural decision in your MVP hasn’t been tested in production yet?

Reply to this email — I’ll help you stress-test it with a simple walking skeleton example on LinkedIn.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

3️⃣ Chapter 3 – Fake it ‘till You make it

4️⃣ Chapter 4 – Validating the problem/opportunity or the solution?

5️⃣ Chapter 5 – Prioritizing Features (with Stakeholders)

6️⃣ Chapter 6 – Implementing core and nice to have features

7️⃣ Chapter 7 – Managing internal expectations

8️⃣ Chapter 8 – Keeping MVP Scope Alive While Building

9️⃣ Chapter 9 – Best Practices for Defining and Planning an MVP → You’re here.

1️⃣0️⃣ Chapter 10 – Working skeleton: pipeline first → Coming on January 13th, the first chapter of the new section: Building the MVP!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Why an MVP Needs Method, Not Guesswork

Planning an MVP is not about shrinking a big product idea into a small version.

It’s about identifying the minimum set of features that validate the solution, delivered in the fastest, simplest, most learning-oriented way possible.

Over the past chapters, we explored the decisions that make or break this process.

This final issue summarises them into a set of actionable best practices — a checklist you can return to any time you start a new product or feature initiative.

🧭 Best Practices for Defining and Planning an MVP

Here’s the complete toolkit we’ve explored so far.

1. Start with the problem, not the product

Before thinking about features, validate that:

• The problem is real

• It is painful

• It happens often enough

• The target users care

• There’s a clear opportunity to solve it

Use low-cost validation: interviews, simple landing pages, surveys, manual workflows, ads, and AI-assisted insight clustering.

Do not define the solution until the problem is strong and proven.

2. Make your hypothesis explicit

Every MVP begins with:

“We believe that [segment] has [problem], and that [solution] will solve it.”

If this cannot be formulated clearly, the MVP will fail by definition.

This is your compass for every decision.

3. Identify the core feature (and keep it sacred)

The core feature is the one action the user must take to experience the product’s value.

Everything else is supporting detail.

Rules:

• If it does not directly validate the hypothesis → it’s out

• If it can be postponed → postpone it

• If it can be simplified → simplify it

A bloated MVP is not an MVP.

4. Separate core features from nice-to-haves

A simple but powerful rule:

• Core = essential to validation

• Nice-to-have = everything else

Nice-to-haves don’t belong in an MVP.

If you really must include one, build the simplest possible version and expect to rebuild it later.

5. Use the “fake it till you make it” principle intentionally

Automation is expensive.

Validation is cheap.

Any non-critical operational flow can initially be:

• Manual (email, spreadsheet, form submission)

• Semi-automated (Zapier, n8n, Make, Bubble, Softr)

• Simulated (Wizard-of-Oz prototype)

Every hour you don’t spend on early automation is an hour you can spend learning.

6. Choose technologies that maximise speed and feedback

The best tech stack for an MVP is the one the team can:

• Build quickly

• Maintain without effort

• Deploy continuously

• Adapt without friction

• Throw away if needed

Use tools you know, explore new technologies only if they significantly reduce time-to-learn.

Keep architecture minimal and reversible.

7. Build an architecture that can evolve

The architecture itself can be an MVP — a walking skeleton:

• One repo

• One deploy pipeline

• One vertical slice working end-to-end

• Minimal abstractions

• Everything replaceable

Avoid premature modularisation, microservices, or heavy orchestration.

You don’t need scale before having users.

8. Prioritise by impact, not effort

Effort estimates do not help prioritisation.

Impact (on validation) is the only variable that matters.

A feature that requires a week can be more important than one that takes a day if it’s essential to proving the solution.

Impact decides order.

Effort only informs slicing.

9. Keep scope alive throughout development

Scope is not a static document.

It’s a hypothesis that evolves through daily learning.

To keep it alive:

• Turn standups into alignment sessions, not status reports

• Re-evaluate priorities continuously

• Update the scope weekly

• Cut scope as soon as risks or delays appear

• Replace expensive features with manual or low-code versions when needed

Sticking to outdated scope is not discipline — it’s waste.

10. Communicate constantly and transparently

Internal alignment is a core part of MVP success.

Use:

• A lightweight public roadmap

• A simple idea intake process

• Weekly learning updates

• Decision logs (reversible vs irreversible choices)

• Shared expectations with stakeholders

Clarity reduces noise, prevents scope creep, and keeps focus on validation.

11. Slice features vertically

A thin vertical slice is always better than multiple incomplete horizontal layers.

Each slice should include:

• Minimum UI

• Minimum backend

• Minimum workflow

• Full deployment path

If it doesn’t run end-to-end, it doesn’t teach you anything.

12. Document decisions, not just features

A good MVP doc includes:

• The hypothesis

• The core feature

• The IN/OUT list

• The rationale behind exclusions

• Scope changes over time

• Reversible vs irreversible decisions

• What you expect to learn

Documentation builds confidence, alignment, and speed.

🎁 Outro — End of Year & Teaser for What’s Next

With this chapter, we close the first section of the Practical Handbook:

First Steps: Idea, Validation, MVP.

We talked about problem validation, core features, prioritisation, fake-it-till-you-make-it, scope management, and everything needed to plan an MVP that delivers learning instead of waste.

After the holidays, we’ll enter the second section:

“Building the MVP”

where we’ll go hands-on with topics like:

• Walking Skeletons: getting your first end-to-end flow running

• Architecture That Can Evolve: making choices that don’t trap you

• Releasing in Thin Slices: shipping value continuously

• Simplifying Without Lowering Quality: how TDD and CI help MVP velocity

• How to Avoid Over-engineering During Build

A different section, with more examples, more code, and more real product stories.

Have a great end of the year — see you in January with the next chapter.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

3️⃣ Chapter 3 – Fake it ‘till You make it

4️⃣ Chapter 4 – Validating the problem/opportunity or the solution?

5️⃣ Chapter 5 – Prioritizing Features (with Stakeholders)

6️⃣ Chapter 6 – Implementing core and nice to have features

7️⃣ Chapter 7 – Managing internal expectations

7️⃣ Chapter 8 – Keeping MVP Scope Alive While Building → You’re here.

8️⃣ Chapter 9 – Technical and generic suggestions to develop an MVP effectively → Coming next week, the final chapter of the first section!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

On paper, the MVP scope looked perfect: a clean list of features, prioritised and documented. But two weeks into development, reality kicks in:

• A feature takes longer than predicted

• A dependency appears out of nowhere

• A stakeholder adds “just one more thing”

• The team uncovers new learning that affects the plan

• The deadline stays still while complexity grows

If the scope stays static while reality changes, teams start drifting.

They either:

(a) try to force the original plan (and burn out)

(b) start improvising solutions (and lose the MVP’s purpose)

(c) deliver everything except the core value (and fail to validate the solution)

At the root of the problem is a misconception:

Scope is not a contract. Scope is a hypothesis.

And hypotheses evolve as you learn.

The MVP scope must stay alive.

It must adapt to new information, feedback, blockers, discoveries, and actual velocity.

This requires two things:

1. Effective daily communication (not status reporting)

2. A willingness to re-prioritise fast when the plan no longer matches reality

Static scope creates static teams.

Living scope sustains learning.

⚡ Why It Matters

Keeping the MVP scope alive is what separates teams that ship in 30–60 days from those that sink into six-month “MVPs” that are no longer minimal nor viable.

Here’s why this chapter is critical:

1. The goal of an MVP is to validate a solution, not to complete a checklist

If new learning changes what matters, the scope must change with it.

Rigid scope kills outcomes.

2. Scope that doesn’t move becomes a lie everyone works around

Teams pretend everything is fine until the final week…

…then cut features in panic mode, damaging quality and credibility.

3. Daily standups are your scope-maintenance engine

A good standup is not a status update.

It is:

• What do we need to move closer to the MVP goal today?

• What is blocking us from validating the solution?

• Does our current plan still make sense?

• Should we drop or “simplify-to-learn” something?

Done right, standups surface the truth early.

4. Priorities shift — and that’s healthy

New information = new priorities.

Same goal, new path.

5. A living scope protects your timeline

If the deadline is fixed (MVPs usually are), the only flexible variable is scope.

And the earlier you adjust it, the cheaper it is.

🛠 How We Solve It

Here’s the practical, product-first, engineering-aware playbook.

1. Turn standups into daily alignment, not reporting

Bad standup:

“What I did yesterday, what I’ll do today, blockers.”

Sounds good, teaches nothing, aligns nobody.

Great standup:

• What is the next slice needed to validate the MVP?

• Are we still on track to validate the core feature?

• Do we need to simplify something today?

• Did we learn something yesterday that affects priorities?

• Are we working on the right thing right now?

• What progress do we expect to achieve today?

Use a shared Notion/Linear page titled:

“Today’s focus to reach MVP validation”

Updated collaboratively every morning.

AI can help:

• Slack standup summaries via Standuply, DailyBot, tl;dv

• AI clustering of blockers or repeated themes

• Automatic scope update suggestions (“this item has been blocked for 3 days — consider moving it down or simplifying it”)

2. Keep the scope visible and editable

Scope should not live in a static document.

It must be visible every single day.

Use tools like:

• Linear cycles with IN / OUT list

• Notion Kanban dedicated to MVP scope

• Coda with live tags and reasoning

• Figma FigJam for visual scoping

Every day:

• Update status

• Drop items

• Move things to “Maybe Later”

• Reorder priorities

• Add small “fake-it” or “manual-first” cards

Scope is not sacred.

Validation is.

3. Re-prioritise continuously — not once per sprint

If you realise on day 7 that Feature C is too big…

Don’t wait for sprint planning.

Move it out, simplify it, or replace it with a manual version.

Impact dictates priorities, not effort.

A good rule:

• If a feature is not essential for validation → it is optional

• If something becomes more important after learning → move it up

• If something becomes less relevant → move it down or out

You’re not “breaking the plan”.

You’re refining the hypothesis.

4. Scope cuts are not failures — they’re strategic

When the team realises a scope cut is needed, they often hesitate:

“It feels like giving up.”

“It looks bad to stakeholders.”

“It feels like rework.”

But scope reductions done early are signs of maturity.

Types of positive scope cuts:

• Cutting a feature entirely

• Replacing it with a manual operation

• Shipping an ultra-simplified version

• Using a low-code/no-code version first

• Deprioritising a nice-to-have

If quality validation remains intact, the cut is a win.

Use tools like:

• Zapier, Make, n8n → to automate manually first

• Bubble, Softr, Glide → to deliver the skeleton of a feature

• Figma → AI → code to prototype faster

• Google Sheets as backend for simple flows

Scope is a cost.

Cuts save time, reduce waste, and increase learning speed.

5. If you didn’t prioritise well before development — fix it now

Sometimes teams start building before the MVP is fully sliced.

When this happens, acknowledge reality:

“We should have prioritised earlier. So let’s do it now.”

Steps:

• Run a quick prioritisation session using Impact over Effort

• Tag each feature Core vs. Nice-to-Have

• Move Nice-to-Haves to “out” unless they provide immediate learning

• Rescope Core features (simplify further if needed)

• Align with stakeholders (send a short summary, not a meeting)

Late prioritisation is not ideal, but better late than never.

6. Use new information to update priorities — instantly

If yesterday’s learning invalidates Feature B → cut it.

If user interviews show a different pain → elevate the feature that addresses it.

If engineering discovers complexity → simplify or replace.

If timeline becomes tight → reduce scope before quality.

Remember:

Learning events are scope-changing events.

A living scope responds to reality — not to the initial plan.

⚖️ Trade-offs

• A living scope requires constant communication — but reduces panic later

• Re-prioritisation may frustrate some stakeholders — but protects the MVP’s purpose

• Cutting scope reduces completeness — but increases learning

• Fake-it versions reduce engineering effort — but increase manual work

• Low-code patches move faster — but must be reviewed post-MVP

You trade comfort for clarity.

Stability for truth.

Completeness for validation.

🚀 Next Steps (Tomorrow Morning)

1. Open your current MVP board. Tag everything as:

   • Core for validation

   • Optional for delight

   • Manual-first candidate

   • Low-code candidate

   • Out

2. Rewrite your standup to be goal-focused:

   • “What helps us validate today?”

   • “What blocks validation?”

   • “What can we simplify or cut?”

   • “What progress we expect today?”

3. Review the bottom half of your scope list.

   Move 50% of it out or convert into fake-it / no-code versions.

Your MVP will instantly become lighter, faster, and more aligned.

What part of your current MVP scope feels too heavy or over-engineered?

Reply to this email — I’ll help you simplify it in a Linkedin post.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

3️⃣ Chapter 3 – Fake it ‘till You make it

4️⃣ Chapter 4 – Validating the problem/opportunity or the solution?

5️⃣ Chapter 5 – Prioritizing Features (with Stakeholders)

6️⃣ Chapter 6 – Implementing core and nice to have features

7️⃣ Chapter 7 – Implementing core and nice to have features → You’re here.

8️⃣ Chapter 8 – Keep the MVP scope alive during development → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You’re in the middle of building an MVP. Engineering is focused, product is slicing scope, the walking skeleton is in motion. But around you? Confusion.

Sales expects one set of features. Marketing expects another. Support has a list of urgent needs. The CEO sends you a Slack message at 23:00 asking, “Where are we with X?”

It’s not that these expectations are unreasonable — it’s that expectations were never explicitly set, so everyone fills the silence with their own assumptions.

This creates a familiar pattern inside many startups:

• The product team moves with a hypothesis-driven roadmap… but stakeholders assume feature-driven delivery.

• Ideas enter the system in every possible way (meetings, Slack DMs, phone calls) with no visible intake or decision-making process.

• “When will feature X be ready?” becomes the only conversation, instead of “What are we validating right now and why?”

The result:

• The roadmap gets interpreted as a fixed promise instead of a directional narrative.

• The MVP scope inflates to satisfy unspoken expectations.

• Engineering becomes reactive instead of learning-driven.

• Stakeholders lose trust because they feel ignored or vaguely updated.

• Product loses leverage because decisions look arbitrary instead of transparent.

The core issue is not misalignment — it’s unmanaged expectations.

The solution is not more process — it’s better communication.

⚡ Why It Matters

Managing internal expectations is not a “nice to have”. It’s foundational to shipping an MVP fast, confidently, and with company-wide support.

Here’s why:

1. Alignment drives speed

The organisation moves at the speed of its shared understanding.

A clear and visible roadmap reduces interruptions, resets expectations, and gives the whole company a single source of truth.

2. Transparency protects product autonomy

When stakeholders see the “why” behind decisions — including what’s not being built — they stop trying to overload the MVP with nice-to-haves.

The trade-offs become obvious instead of political.

3. Expectations shape behaviour

If the roadmap is seen as a contract, risk-taking dies.

If it’s seen as a learning plan, the team gains permission to experiment.

4. Clear communication improves trust

People rarely get angry at “no”—they get angry at silence.

A visible idea intake → review → outcome loop gives psychological safety: everyone knows their input is processed, even if not accepted.

5. It prevents “shadow roadmaps”

If you don’t provide an official roadmap, every stakeholder creates their own version — often outdated, unrealistic, or misaligned.

In short: expectations are a strategic lever. If you don’t manage them intentionally, they will manage you.

🛠 How We Solve It

Here’s an expanded, practical, tool-supported playbook for managing internal expectations inside a startup or product-led team.

1. Publish a lightweight public roadmap (keep it simple)

The roadmap isn’t a project plan. It’s a narrative artifact that communicates priorities and the current learning focus.

How to do it:

• Create one page in Notion, Linear, Miro, or Coda.

• Structure it using high-level buckets like “Now / Next / Later” or “Exploring / Building / Validating”.

• Focus on themes, not features (“Improve onboarding” > “Add OAuth login”).

• Add a visible disclaimer:

“This roadmap expresses our current priorities and learning goals. It will evolve based on user feedback and validated learning.”

• Use AI to automatically generate versions for different audiences (e.g., simplified for sales, detailed for internal devs).

What you avoid:

• Feature promises you can’t keep

• Misinterpretation of scope

• Constant “what’s the status?” pings

2. Create a simple idea intake and feedback loop

Not a process. Not bureaucracy. Just one lightweight system that shows:

idea → triage → decision → communication.

Build it like this:

• Use Tally, Google Forms, Typeform, or a Notion Form.

• Ask for only 3 fields:

  1. What problem does this solve?

  2. Who benefits?

  3. Why now?

• Store submissions in a Notion or Airtable table.

• Use Zapier / Make / n8n to auto-tag ideas (e.g., “growth”, “retention”, “support”).

• Use AI weekly to summarise new ideas and cluster them by problem area.

• Host a 15–20 minute biweekly evaluation with PM + Tech Lead.

• For each idea, mark:

  • In Scope

  • Later (parked)

  • Out (with rationale)

Pro tip:

Send an automated message back to the submitter (“Reviewed — here’s the outcome”).

Silence kills trust; transparency builds it.

3. Use storytelling and metric-based updates

Stakeholders don’t want to understand your architecture — they want to understand your progress, risk, and learning.

How to do it effectively:

• Use Loom or Descript AI to record quick demos of thin slices or manual workflows.

• Keep a “weekly update” in Notion or Slack:

  • What we delivered

  • What we learned

  • What changed in the roadmap

  • What’s next

• Use AI summarisation to create short versions for Slack, email, sales, support.

• Create a simple metrics dashboard using Looker Studio, Metabase, or even a Notion database (activation, retention, usage).

This transforms your communication from reactive to proactive.

4. Maintain expectation hygiene (be explicit)

Every commitment should include:

• What we’re building

• What we’re not building

• Why

• When we expect to validate

Use tools:

• IN / OUT lists shared before every sprint or cycle.

• A decision log: reversible vs irreversible decisions (two-way vs one-way doors).

• AI-assisted summaries of decisions for non-technical stakeholders (“Rephrase this for sales”).

This creates clarity and prevents scope creep disguised as “quick wins”.

5. Celebrate the momentum (not just the walking skeleton)

You don’t need to celebrate only when something is fully shipped.

Celebrate learned, tested, validated, iterated, or unblocked.

Examples worth celebrating:

• The first end-to-end thin slice

• A manual workflow that proves value before automation

• The first user interaction with the prototype

• A low-code automation replacing a manual task

• A metric improving after an experiment

Use AI tools to make celebration easier:

• Create micro-videos with Descript

• Auto-generate update images with Gamma.ai

• Turn logs into updates with Notion AI

Momentum is contagious.

If you don’t show it, the organisation assumes you have none.

6. Apply the same alignment inside the product+engineering team

Expectation misalignment isn’t only external — it’s internal too.

Keep the team aligned:

• Keep a shared Notion page with roadmap, priorities, rationale, and decisions

• Use Slack bots + AI recaps (tl;dv, Clarity) to surface meeting outcomes

• Revisit idea submissions during grooming so engineers see the full picture

• Use retros to discuss where expectations went off track

When engineers understand the “why”, everything accelerates.

⚖️ Trade-offs

• Too much detail overwhelms stakeholders; too little leaves them guessing.

• A roadmap updated too often feels unstable; too rarely feels dead.

• Too much process slows down speed; too little produces chaos.

• Radical transparency is good — but must be curated for audience.

• A great communication flow takes effort — but pays back in speed, trust, and sanity.

🚀 Next Steps (tomorrow morning)

1. Create a one-page internal “Product Communication Charter” in Notion, describing:

   • How ideas come in

   • How decisions are made

   • How the roadmap is updated

   • How updates are shared

2. Build a simple idea intake form in Google Forms or Tally. Connect it via Zapier to a Notion database.

3. Publish your first lightweight roadmap in Notion or Linear. Add the “subject to change based on validated learning” disclaimer. Share with the company.

Do these 3 things and you’ll see your organisation shift from “What’s going on?” to “We’re aligned.”

Where does expectation misalignment hurt you the most today — with stakeholders, or inside your team?

Reply and tell me. I’ll include a few anonymised examples in a Linkedin post.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

3️⃣ Chapter 3 – Fake it ‘till You make it

4️⃣ Chapter 4 – Validating the problem/opportunity or the solution?

5️⃣ Chapter 5 – Prioritizing Features (with Stakeholders)

6️⃣ Chapter 6 – Implementing core and nice to have features → You’re here.

7️⃣ Chapter 7 – Implementing core and nice to have features → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

When you’re launching an MVP, the feature wish-list grows fast: “Let’s add social login, analytics, multi-language, offline mode…” And while all these may look appealing, the real danger is that you bundle so many features that you lose sight of the MVP’s goal: validating the core value proposition.

Teams often treat all features as equal. They decide “Feature A = 3 days”, “Feature B = 4 days”, so why not do both? But if the “must-have” that actually solves the user’s main problem gets treated the same way as a “nice-to-have” decoration, you risk two things: First, you delay shipping something valuable. Second, you build complexity you’ll likely discard.

Technical teams also react differently depending on feature type. For core features, engineers may assume “we must do it perfectly”. For nice-to-haves, they may say “we’ll do a quick version, then fix”. The problem: quality trade-offs aren’t the same in both cases. A core feature with weak quality may undermine the product’s credibility; a nice-to-have with high quality wastes time and energy.

In startup mode, you often have only 30-60 days to deliver. The rest of the organisation moves fast. If your team tries to treat every feature as equal, you’ll slow down, scope will creep, and you’ll arrive at “MVP1” that looks like “v0.1 of full product” — and learn nothing. You need to clearly differentiate core vs nice-to-have before you design the system.

⚡ Why It Matters

Core features are the ones without which your product doesn’t deliver value. They are the reason a user chooses you. Nice-to-haves add polish, differentiate, delight — but they don’t make or break your MVP.

Because of this distinction:

• The technical investment you’re willing to make changes. For core features you may accept higher engineering quality, better testing, even more robust architecture, because failure here means your product fails.

• For nice-to-haves, you should treat them as optional or deferred. If you include them in the MVP, they should be minimal versions, with less testing, less polish — possibly even as manual or simulated features.

• Treating all features equally means you allocate time and quality budget incorrectly. Many sources on MVPs emphasise avoiding feature-bloat and focusing on “must-have” elements.

• Architecture must reflect this. Your system should prioritise the core features for reliability, simplicity, and scalability later; the nice-to-haves should live in less-rigorous territory until validated.

In effect, distinguishing core vs nice-to-have lets you allocate your limited time, budget, and engineering capacity to what matters most. You increase your chance of learning something meaningful — instead of building a shiny toy.

🛠 How We Solve It

Here’s how to apply this distinction in practice:

1. Define core vs nice-to-have

   • Write down your feature list. For each feature ask: “Without this, can the user still derive our value proposition?” If no → core; if yes → nice-to-have.

   • Use frameworks like MoSCoW (Must/Should/Could/Won’t) or the 80/20 rule (20% of features deliver 80% of value) to formalise.

2. Adjust technical & quality standards accordingly

   • For core features:

     • Prioritise automated tests (unit + integration)

     • Deploy via CI/CD

     • Use an evolutionary architecture that allows growth but starts small (walking skeleton)

   • For nice-to-have features:

     • If included in MVP, build a minimal version (e.g., manual workflow, no automation)

     • Fewer tests, simpler design, faster to implement

     • Mark as “to revisit post-MVP”

3. Use no-code/low-code and AI tools especially for nice-to-haves

   • Accept that if something is “nice, not core” you might build it with Bubble, Glide, or a Zapier workflow.

   • Use AI tools for prototyping: generate UI layouts, mock APIs, simulate feature behaviour. This reduces cost and speeds iteration.

   • Later, when usage is validated, you can decide to rewrite in code with full architecture. But treat that rewrite as a one-way door decision, and only after data supports it.

4. Document your decisions and scope

   • Maintain a feature register: each feature tagged with “Core / Nice-to-Have”, quality standard, implementation path (no-code/manual/auto).

   • Capture architecture choices: which modules, which tech stack, which parts are future bets.

   • This documentation keeps stakeholders aligned and allows you to defend quality trade-offs: “Yes, this feature is nice-to-have, so we’ll launch it manual and improve later.”

5. Review and iterate post-MVP

   • After launch, evaluate usage: are core features performing? Are nice-to-haves being used?

   • Based on data, decide which nice-to-have should be elevated to core, which should be deferred, and which should be removed.

   • Update your architecture accordingly: move features from no-code/manual to code only when justified.

⚖️ Trade-offs

• Over-investing in nice-to-have features (quality, automation) steals cycles from life-or-death core features.

• Under-investing in core features means you deliver something unstable, users bounce, you miss the hypothesis.

• Manual/no-code flows for nice-to-haves work early, but if you never decide to rewrite them, you accumulate hidden technical debt and UX issues.

• Delaying architecture decisions is fine until you’ve validated. But delaying too much for core functionality may cause rework and slow down later growth.

🚀 Next Steps (tomorrow morning)

1. Categorise your current backlog: tag each feature as Core / Nice-to-Have and mark its planned quality standard (code/manual/no-code).

2. For each Core feature, ensure you have an end-to-end slice built, tested via CI, and deploy-ready. For each Nice-to-Have in MVP, plan a manual or no-code deliverable or defer it entirely.

3. Create a “feature queue” for Nice-to-Haves: set a trigger metric (e.g., 1,000 users or 20% adoption) before upgrading to full code. Store this queue in your documentation.

📎 Primary Resources

• Designli — How to Define Your MVP’s Core Features

• Decodifi — How to Define the Core Features of Your MVP

• Crowdbotics — How to Know Which Features You Should (and Shouldn’t) Include in an MVP

Which feature in your current MVP list would you tag as “Nice-to-Have” and remove or convert to no-code for now? Reply and tell me — I’ll feature one example in the next issue.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

3️⃣ Chapter 3 – Fake it ‘till You make it

4️⃣ Chapter 4 – Validating the problem/opportunity or the solution? → You’re here.

5️⃣ Chapter 5 – Prioritizing Features (with Stakeholders) → You’re here.

6️⃣ Chapter 6 – Implementing core and nice to have features → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

When building an MVP, countless feature ideas surface: “What about X?”, “Our competitor has Y”, “Let’s add Z now so we don’t rewrite later”. Without clear prioritisation, the backlog becomes a free-for-all, development drags, and the core goal of the MVP — validate the solution — gets buried under feature overload.

Worse: teams equate prioritisation with estimating effort. “This one is 3 days” vs “that one is 10 days”. But the real question is not how long; it’s how much value it delivers. If you spend 10 days on a low-impact feature because it was “easy”, you steal time from high-impact work that validates your hypothesis.

Stakeholders complicate things: marketing wants “delightful features”, product wants “nice to have”, sales demands “dashboard”. Without a structured prioritisation process, every voice becomes equal, and the MVP scope becomes uncontrolled.

When your MVP scope balloons, you risk missing your time box (30–60 days), losing the walking skeleton momentum, and delivering something that is feature-rich but value-poor. The team behind the scenes becomes slow, even though the business expects speed. This mismatch kills early product-developer credibility.

In short: Prioritisation is not optional. It’s the scaffold that lets you keep scope minimal, stay aligned with stakeholders, and focus on solving the right problem — not building everything.

⚡ Why It Matters

Prioritising features with purpose matters because it aligns three critical axes — value, time, and stakeholder trust — and transforms the MVP execution from a tactic into strategic validation:

• Impact first, effort second. Frameworks like the Impact/Effort Matrix highlight that value to the user and business should outweigh raw development cost.

• Scope clarity equals speed. Prioritisation gives you a concrete IN list and an OUT list. When everyone understands what doesn’t get built — and why — scope discussions vanish and velocity rises.

• Stakeholder alignment. Using prioritisation frameworks makes discussions observable and objective. It prevents “my pet feature” wins and forces trade-offs to be explicit.

• Validating what matters. You prioritise features that test your hypothesis, not features that fill up your backlog. This focus ensures the MVP remains a learning tool, not just a busy box.

• Avoiding the effort trap. Estimations are inherently unreliable early on; relying on them to prioritise is a mistake. A feature may be tagged “low effort” but deliver zero value; or “high effort” yet unlock major learning. Practice shows impact drives outcomes more than effort prediction.

In essence: a well-prioritised backlog is your control panel. Without it, you are blind.

🛠️ How We Solve It

Here are practical steps you can apply to prioritise features with stakeholders — keeping the focus on impact, not development effort.

1. Set the prioritisation criteria upfront.

   • Define what “impact” means for the MVP: e.g., number of users adopting the feature, revenue potential in 3 months, reduction of manual work by X%.

   • Agree on “ease” or “cost” but treat it as context, not decision driver.

2. Choose a prioritisation framework.

   • Use Impact/Effort Matrix to visualise features: high-impact low-effort go first.

   • Use MoSCoW (Must/Should/Could/Won’t) to classify features quickly.

   • Avoid RICE (Reach, Impact, Confidence, Effort) and any other effort-based approach.

   • Choose the tool that suits your team’s maturity. The goal: drive alignment and speed, not debate forever.

3. Lead stakeholder workshops with structure.

   • Pre-work: send a one-pager describing the MVP goal, core hypothesis, list of candidate features with business/user context.

   • Workshop format:

     • For each feature: ask “What problem does this solve?”, “How many users will this impact?”, “How will we know it worked?”

     • Plot features on Impact/Effort grid live.

     • Build consensus on the IN list (top quadrant) and the OUT list (low impact or high cost).

   • Document decisions real-time. Distribute the “IN/OUT” list after the workshop.

4. Keep “effort” estimates as context, not ranking criteria.

   • When someone argues “but this takes 2 days vs 10 days”, respond: “Okay – but will it move the metric we care about more than others?”

   • Highlight that effort is uncertain and shouldn’t delay high-impact work. The feature’s priority is based on impact.

5. Embed no/low-code and AI tools into the prioritisation conversation.

   • Highlight features that can be prototyped with no-code (e.g., Carrd, Bubble) or AI (e.g., GPT-4 prototype, Figma-generated UI) as low-investment experiments.

   • Use these quick prototypes to validate value before coding full solutions. Features that succeed via no-/low-code often get built later in code with stronger evidence.

   • During workshop: add a column “Prototype possible?” (Y/N). Those yes entries get fast-tracked for learning.

6. Revisit decisions frequently.

   • Prioritisation is not once-and-done. As you gather feedback, metrics may change. Use regular check-ins (every sprint or every 2 weeks) to review the IN/OUT list.

⚖️ Trade-offs

• Highest impact features may take longer → you delay smaller quick-wins. That’s okay if your hypothesis is big enough and you stay committed to fast feedback.

• Quick wins feel cheap but may not validate the core problem → you might build ability to do X but not find whether users care about X.

• Low-code prototyping accelerates validation but may mask tech debt → if you commit to no-code without plan to replace, you may carry hidden cost.

• Stakeholder consensus helps alignment but risks lowest-common-denominator → keep the criteria strict to avoid “everyone wins” outcomes.

🚀 Next Steps (tomorrow morning)

1. Draft your feature list: include 8–15 candidate features tied to your MVP hypothesis.

2. Define “impact” for your product (user metric, cost reduction, activation rate), and rank each feature by that metric — ignore effort for now.

3. Schedule a 1-hour prioritisation workshop with your key stakeholders: walk through the list, apply an Impact/Effort grid, decide the IN/OUT list. Distribute the results.

📎 Primary Resources

• Atlassian – Six Product Prioritisation Frameworks & How to Pick.

• Product School – Impact Effort Matrix & How to Use One + Examples.

• Optimizely – What is Feature Prioritisation? Five Methods and Examples.

What feature do you and your stakeholders disagree most about — and how confident are you in its impact?

Reply to this email. I’ll pick 2-3 to walk through in the next issue (with crowd feedback).

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

3️⃣ Chapter 3 – Fake it ‘till You make it

4️⃣ Chapter 4 – Validating the problem/opportunity or the solution? → You’re here.

5️⃣ Chapter 5 – Features prioritization strategies → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

You’ve got a glimmer of an idea—a tech-startup moment of insight. Maybe you saw a process that drags on, a customer always complaining, a manual workflow that could be digitised. So you dive straight into building. You sketch the UI, pick your tech stack, start writing code. But after weeks or months you realise: users don’t care as much as you thought. Or the value you promised doesn’t land. Why? Because you validated the solution, not the problem.

When you jump to solution-mode too fast, you’re building “just in case” instead of “because.” You assume the underlying problem is big, urgent and unserved. You assume your proposed solution will work. But if those assumptions aren’t true, you’ll have built fast — and failed faster.

The right order is:

1. Validate that the problem/opportunity exists and is meaningful.

2. Only then validate if your chosen solution addresses it in a way users will adopt.

For example: if you believe “small business time-tracking is broken” (problem) you validate that first — ask how often they track, what they hate, what they do instead. Once you see urgency, a workaround, willingness to change — then you build “our time-tracking app.” If you built the app first, you risk discovering they’re okay with spreadsheets and don’t care about switching.

The cost of skipping intention is high: you end up locked into technical choices (one-way-doors) before you know you had a market problem. Meanwhile you miss flexible, reversible decisions (two-way-doors) that would have given you speed and cheap learning.

⚡ Why it matters

Getting this order right matters because it dramatically changes your odds of success and the shape of your technical and product decisions.

• Reducing waste early. Validating a problem costs far less than developing a full feature set. As one article puts it, one of the top reasons startups fail is “solving problems nobody cares about”.

• Keeping your options open. If you validate the solution too early, you may lock in architecture, UI flows and tech stack before you understand usage. Two-way‐door decisions (e.g., UI layout, backend choice) should happen early; one-way‐door decisions (e.g., core database, major business model) should wait for problem/solution validation.

• Aligning product, business and tech. Validating the problem means you understand user desire, pain severity and willingness to switch. That clarity helps you choose the right scope, the right features and the right metrics. Then—you build the solution with discipline and speed.

• Shaping your business model correctly. If the problem isn’t urgent, your solution may not be paid for or adopted. Validating the problem ensures that when you validate the solution, you’re testing something meaningful—not vanity features.

• Making simpler, faster architecture and MVP choices. When the problem is clear, you can build a walking skeleton, adopt evolutionary architecture and keep the scope thin because you’re focused on learning one thing well—not shipping everything poorly.

🛠️ How we solve it

Here’s a practical roadmap you can apply.

1️⃣ Formulate your hypothesis

Write it as a testable statement:

“We believe [user segment] has [problem] that causes [pain], and they are willing to pay/use [solution].”

Make it concrete and falsifiable — if it can’t be disproved, it’s not a hypothesis.

2️⃣ Validate the problem first — fast and cheap

• Talk to humans before writing code. Do 5–10 user interviews focused on pain, frequency, and urgency. Avoid showing your solution idea too early — you’ll bias feedback.

• Use AI/no-code tools for discovery, some examples:

  • 🧩 Typeform, Google Forms or Fillout for quick surveys.

  • 🌐 Carrd, Webflow, or Framer for simple landing pages.

  • 🤖 Lovable or Bolt.new to quickly create an MVP or “realistic prototype”

  • 📣 Run small ad experiments on Google or Meta to test demand (“Sign up for early access”).

• Leverage AI for insight extraction:

  • Use ChatGPT or Perplexity to summarize user interviews, cluster recurring pain points, and detect language patterns (“What words do users use to describe this problem?”).

  • Feed transcripts into a vector DB (e.g., Supabase + OpenAI embeddings) to query later.

• Measure signals, not opinions. Count how many people click, sign up, or reply “I’d pay for this.” Interest is a better signal than agreement.

Keep everything flexible: at this stage, nothing should require hard technical choices.

3️⃣ Define and validate the solution only once the problem signal is strong

When you have evidence the problem is real and painful, define the smallest possible solution that proves your hypothesis.

• Start with one feature. The core capability that directly addresses the pain. Anything else is out.

• Prototype with low-code and AI first:

  • Use Bubble, Glide, or Softr to build the working prototype.

  • Use Zapier, n8n, or Make for quick process automation behind the scenes.

  • Use AI code assistants (e.g., Replit AI, GitHub Copilot, v0.dev, Lovable) to generate UI scaffolds or backend templates in minutes.

• Simulate or semi-automate when needed (Wizard-of-Oz MVP):

  • Example: accept user inputs but process them manually in a spreadsheet for early users.

  • Replace the manual step with code only when it becomes the bottleneck.

• For coded parts, keep architecture evolutionary:

  • Use a single repo and a walking skeleton that runs end-to-end from day one.

  • Keep layers thin and replaceable — one service, one database.

  • Automate deployment early (CI/CD) to build confidence while staying lean.

  • Delay irreversible design choices (one-way doors) until you have user data.

The goal is to validate value, not to build infrastructure.

4️⃣ Keep tech and feature choices reversible

• Tag every decision: one-way or two-way door.

  • One-way: foundational architecture, data model, contracts — delay.

  • Two-way: landing page copy, component layout, integration provider — decide fast.

• Use no/low-code tools deliberately:

  • Treat them as temporary scaffolding: something to replace later when scale or cost demands.

  • Or, if they prove stable and cheap to maintain, integrate them safely as part of your long-term system — encapsulated behind APIs, monitored, and versioned like any other component.

• Budget their replacement upfront. Assume every no-code component has a future rewrite cost. Document it and track it as technical debt, not surprise.

5️⃣ Document everything

Keep a single, living document (Notion, Linear, Confluence — doesn’t matter) with:

• ✅ The problem and solution hypotheses.

• 📊 Metrics and signals that confirm or disprove them.

• 🚪 Decision logs: what’s in/out, what’s a one-way door, what’s temporary.

This discipline gives you clarity when you revisit assumptions or scale up.

⚖️ Trade-offs

• Problem first but no solution build → you may validate pain but miss testing whether your proposed approach actually works. Eventually you still need to build the solution.

• Solution too early → you may build great code for a non-problem. The product might be technically perfect but commercially dead.

• Manual or simulated delivery → fast and cheap, but must be replaced or scaled later or you risk reputation and user experience issues.

• Delaying too many one-way-door decisions → can slow things down if you never decide. Balance is key.

🚀 Next Steps (tomorrow morning)

1. Write your hypothesis for the problem in one sentence. Share it with your team and commit to validating or refuting it.

2. List the pain indicators you expect: how often, how urgent, what alternative do users use now. Run a quick survey or landing-page test to measure one indicator by end of week.

3. Identify one two-way-door decision you can make in the next 48 hours (e.g., landing page design, workflow stub). Decide, implement, learn. Mark all other one-way doors and postpone them until you gather more evidence.

📎 Primary Resources

• Sam Dickie — Start with Problem Validation, NOT Solution Validation.

• Juan Jesús Velasco — The Importance of Validating Problems Before Building the MVP.

• iTonics Innovation Blog — 6 MVP Types for Validating Complex New Products and R&D.

Which assumption about your product are you validating this week — the pain or the approach?

Reply to this email and share your hypothesis. I’ll pick a few for a follow up on a Linkedin post!

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First

2️⃣ Chapter 3 – Fake it ‘till You make it → You’re here.

3️⃣ Chapter 4 – Validating the problem/opportunity vs validating the solution → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

In the rush to ship, many startup teams fall into the trap of over-building early. They design for scale before they have one user, set up full production infrastructure before they’ve confirmed the core value, and build features that only make sense “when we reach 10K users”. Meanwhile, the rest of the business is experimenting, iterating, learning — and the engineering team is stuck trying to perfect architecture.

The core mistake here is confusing product with project. A project is “build this spec, then ship”. A product is “deliver one slice of value, learn, then evolve”. When you treat an MVP like a full release, you end up with a large, slow, expensive version that validates nothing.

Instead, what an MVP needs is to validate the solution, not just the idea. And if you build everything as if you already have full automation, you lose speed. You lose learning. That’s where the principle of “Fake it till you Make it” comes in: build what users see, but you might handle the value delivery manually or semi-automatically behind the scenes. Think “Wizard of Oz” architecture or “Concierge MVP” where you simulate the final product with human operations.

With a 30-60 day window to launch a viable MVP, you cannot wait to build perfect systems. Your architecture must be evolutionary: start with a walking skeleton and enable real learning before you scale. Build simple, see what works, then evolve. If you don’t, you risk being slow because you over-engineered before you even had clarity.

⚡ Why it matters

When you shift to this mindset, you free your team from the tyranny of “perfect first”. You align with speed, feedback and learning. Here’s why the principle is critical:

• Research & tech spikes speed things up. Instead of choosing a new framework on day one and rewriting later, experiment quickly to see what works — then scale. Otherwise you invest time in tech decisions you may never use.

• Prioritize features for learning, not completeness. With a list of IN vs OUT items you guarantee that, if time becomes the blocker, you have done the value delivery first. If you wait too long on secondary features, you ship no value.

• Keep a list of non-must features anyway. Just because they’re out now doesn’t mean you forget them. Documenting the OUT list allows future scope decisions to reference it rather than start from scratch.

• Features must themselves be “MVP versions”. A feature isn’t finished when it’s built; it’s finished when it validates the problem. If you only need two operations, don’t build a full suite of six. Simplify.

• Build to learn, not to perfect. An architecture that evolves wins over one that’s built for all possible use-cases. Evolutionary architecture + walking skeleton = start small, adapt often.

🛠️ How we solve it

Here are practical steps to apply “Fake it until you make it” within your MVP:

1. Create your walking skeleton. Build a thin vertical slice of functionality that works end-to-end: UI ➝ business logic ➝ backend ➝ deploy. Even if manual behind the scenes, the slice must deliver real value to a user.

2. Adopt an evolutionary architecture mindset. Don’t build the entire platform up front. Start small, code by the team, evolve as real data justifies it.

3. Identify your core feature and map manual delivery. Pick the one feature that validates your solution. If automation takes too long, deliver manually for now and mark “automate later”.

4. Classify all other features into must-have vs nice-to-have. If you have more than 5 must-haves, revisit: tie each back to your core problem. For example: do you really need your own login system or can you reuse one?

5. Use “Fake it” experiments like fake-doors, concierge or manual-first delivery. Add a “Pay now” button for a feature that doesn’t exist yet, manually onboard users, manually generate results. Learn their behaviour before coding full stack.

6. Document scope clearly: IN / OUT with reasons. You’ll avoid endless debates and keep the team aligned. When stakeholders push “just one more feature”, you refer to the documented list and explain trade-offs.

7. Always ask: is this a one-way door or a two-way door decision? If reversible, act now. If irreversible, delay until you have data. Engineering in MVP mode thrives on reversible decisions.

⚖️ Trade-offs

• Too minimal ➝ you’ll refactor later; acceptable if you learn quickly.

• Too elaborate ➝ you get stuck in build-mode and learn nothing; dangerous.

• Manual delivery (fake) is fast, but if you don’t automate or evolve, you risk poor scalability or user experience.

• Evolutionary architecture requires discipline, else you accumulate technical debt because you didn’t set boundaries.

• Simulations are valid, but must still deliver user value — fake for speed, not for deception.

🚀 Next Steps (tomorrow morning)

1. Highlight 3 major technical assumptions your team is making (e.g., “we will need multi-tenant DB”, “we need custom workflow engine”, “we need full AI pipeline”). Decide which are one-way vs two-way doors.

2. Define one thin slice: pick a single user flow that delivers value now, automate none or very little, deliver manually if needed. Map what parts are manual vs automated.

3. Write your IN / OUT feature list: mark clearly what must be done for launch and what you’ll purposely exclude. Publish the list to the team and stakeholders for alignment.

📎 Primary Resources

• Fake Doors MVP — Tomer Sharon (Medium)

• 16 Techniques to Validate & Improve Your MVP — mobileLIVE blog

• What is a Minimum Viable Product? – Ironhack blog

What is one feature you’re simulating manually right now — and why?

Reply to this email: I’d love to hear how you’re “faking it” to learn faster.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

📚 Previous on this series

⏩ Section 1 - First steps: Idea, Validation, MVP

1️⃣ Chapter 1 – How to Decide What Goes In and What Stays Out of the MVP

2️⃣ Chapter 2 – Simple Solutions First → You’re here.

3️⃣ Chapter 3 – Fake it ‘till You make it → Coming next week!

🧭 Follow the journey: each issue is a micro-chapter of the series: Practical Handbook for Product Developers — released weekly.

🔎 Scenario / Pain Point

Most startups die of over-building.

Teams design for scale before they have a single user. They worry about performance, permissions, or micro-services when what they really need is a working product that validates one clear solution. The codebase becomes a cathedral for imaginary traffic.

This happens because developers and founders often confuse a product with a project. A project is finished when the spec is implemented. A product is never finished — it evolves through feedback, validation, and learning.

The goal of an MVP isn’t completeness. It’s to learn if your solution works for the problem you’ve identified.

That means starting from the simplest thing that solves that problem, not from the most elegant, extensible, or scalable design.

Yet many engineers still believe that “simple” means “cheap” or “temporary.” It doesn’t. Simple means purpose-driven: just enough to solve the current problem and to let you learn from real use.

If your app only needs addition and subtraction, don’t build multiplication and square roots “for later.” If you only have two types of users, don’t design a full permission system with 14 roles. Every extra abstraction delays learning and adds useless complexity.

In the early phase, speed equals survival. The rest of the company — product, marketing, sales — is moving fast, experimenting daily. Engineering must match that rhythm, not hide behind over-architecture. Otherwise, by the time you finish your perfect foundation, the market has already moved on.

And when startups grow, this slowness often becomes invisible. The rest of the company slows down too, and technical inertia feels “normal.” But that doesn’t make it right — it just turns lack of agility into culture.

⚡ Why it matters

One of the fundamentals elements of a product mindset is the ability to distinguish between what must be decided now and what can safely wait.

Amazon calls this the difference between one-way-door and two-way-door decisions.

• One-way doors are irreversible choices (e.g., foundational tech stack, data model design). Delay them until you have enough information.

• Two-way doors are reversible (e.g., naming conventions, API structure, UI flows). Move through them fast. Learn, adjust, repeat.

In MVPs, almost every decision is a two-way door. Optimize for speed and learning. Don’t over-plan what can be easily changed.

Software development is continuous discovery: learning what users need, what scales, and what to drop. Every line of code should teach you something about your product or your problem space.

That’s why we talk about building to learn, not building to complete.

Each slice you build should:

1. Deliver a tiny piece of real value.

2. Be simple enough to replace or evolve.

3. Generate feedback you can act on.

Techniques like Thin-Slice Development help. Build vertical features, not horizontal layers — an entire “slice of cake,” not a spoonful of frosting. Deliver a full end-to-end experience, however small, instead of shipping disconnected technical components.

Another useful approach is what Alistair Cockburn called a Walking Skeleton — a minimal, end-to-end version of the system that connects all layers, however crudely. It’s not a slice of backend here and a mockup there; it’s a thin vertical cut that actually works from UI to persistence. Once that skeleton is alive, you can evolve it.

That’s where Evolutionary Architecture comes in: the idea that architecture itself should start as an MVP. It must be small, understandable, and adjustable by the team that writes the code. Complexity grows only when the product earns it.

When you design in thin slices, you avoid premature optimization. You can add complexity only when data justifies it.

AI tools make this mindset even more powerful. With generative design and code assistants, you can prototype in hours. Build quick sketches in Figma, generate first UI drafts, and let AI create boilerplate code so your energy goes into validation — not scaffolding.

And the classics still hold true: TDD keeps your code simple by forcing you to write only what’s necessary to make the next test pass. Continuous Integration gives you the confidence to evolve architecture safely, one change at a time.

🛠️ How we solve it

1. Start with a Walking Skeleton.

   Build the simplest vertical slice that proves the system can run end-to-end. One button, one API, one database call. Ship it.

2. Adopt an Evolutionary Architecture mindset.

   Your architecture has its own MVP. It should evolve with the product — not be designed once and frozen. The only constant is the ability to change safely.

3. Focus on the main pain point.

   Every feature must map directly to the problem you’re solving. If it doesn’t, it’s out.

4. Simplify the implementation, minimize the scope.

   Two user roles may be enough. Two workflows may be enough. Remember: you can add complexity later, but you can’t easily remove it.

5. Prototype fast, with tools you know.

   If speed is the goal, build with technologies your team masters. Experiment with new tech only through isolated spikes.

6. Decide through doors.

   For every choice, ask: Is this reversible? If yes, decide fast. If not, delay until data informs you.

7. Build to learn.

   Ship small, measure impact, refactor. Every iteration should reduce uncertainty.

⚖️ Trade-offs

• Too simple: you’ll refactor later — acceptable to learn fast as soon as it’s tested and under control.

• Too complex: you’ll never learn, and you’ll have to live with a lot of wrong choices — fatal.

• Fake solutions: good short-term validation, replace them quickly as soon as they start to be unsustainable.

• Evolutionary design requires discipline, or it can bring to chaos if unmanaged. At the same time, it’s the only way to have a “good enough” architecture under control.

The goal isn’t perfection — it’s momentum with intention. It’s having intentional choices instead of unexpected ones.

🚀 Next Steps (tomorrow morning)

1. List your current architectural decisions. Mark which are one-way and which are two-way doors. Commit only to what you can reverse.

2. Draw your Walking Skeleton. One flow, one data path, one deployment pipeline. Visualize it end-to-end.

3. Ship a thin slice. Deliver one feature that a real user can touch, even if it’s ugly. Learn from it before building anything else.

📎 Primary Resources

• Building Evolutionary Architectures — Neal Ford, Rebecca Parsons, Patrick Kua

• A Walking Skeleton - a minimal initial implementation of an application’s architecture that includes and connects the basic components of the system

• Minimum Viable Product revisited - an article by Kent Beck

Where do you see your team over-engineering right now?

Reply to this email — I’d love to hear one place where “simpler” could get you learning faster.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

🔎 Scenario / Pain Point

Every MVP discussion starts with the same tension: everything feels essential. The designer argues for polished onboarding, sales insists on dashboards, and marketing demands push notifications. Meanwhile, the clock is ticking.

The truth is, building an MVP is not about validating the idea — it’s about validating the solution. You already know the problem you want to solve; now you need to prove that your chosen approach is viable. That means being crystal clear on three things from day one:

• What problem are we solving? If this is fuzzy, no feature prioritization will save you.

• Which technology can we deliver with speed and confidence? MVP timelines are 30–60 days max — you can’t afford to learn everything from scratch.

• Where do we need spikes? If you must touch a new tech, isolate it in small experiments before it contaminates the whole product.

And there’s the budget: an MVP must be cheap enough to fail fast, but solid enough to serve as a foundation. If you cut corners blindly, you’ll end up rewriting from scratch. If you over-engineer, you’ll never ship.

This constant push-and-pull — speed vs. quality, cheap vs. sustainable, minimum vs. lovable — is the real pain point. Without clear criteria, you’ll waste weeks debating and still end up with a bloated backlog that delays the one thing an MVP must deliver: evidence that your solution works.

⚡ Why it matters

Defining an MVP is never just a design exercise — it’s about making deliberate trade-offs that keep you moving fast without sabotaging the future. If you don’t set the right boundaries early, the “minimum” in MVP quickly turns into “months of building” instead of “weeks of learning.”

One of the most underrated moves is researching and spiking on technologies that can accelerate delivery. A half-day spike on a new framework, hosting service, or integration can save you weeks later, either by cutting implementation time or allowing you to fit more scope into the same 30–60 day window. Skipping this step means committing blind to tech choices that may slow you down at the worst moment.

Equally critical is having a prioritized list of MVP features. Why? Because deadlines rarely move. If time beats scope — and it usually does — you want the essentials implemented first. Without clear priority, you risk spending your first two weeks on secondary features, only to realize the core problem is still unsolved by launch day.

It also helps to maintain a separate list of excluded features. You don’t need to treat it as gospel, but it serves as a reference point: when stakeholders ask, “Why isn’t this included?” you can show the trade-offs explicitly rather than debating from memory.

And finally, remember that even features inside the MVP must be “MVP versions” of themselves. Don’t build the perfect onboarding flow — build the simplest version that allows a user to start. Don’t architect the reporting system of your dreams — show a CSV export first. Every extra layer of polish you add delays the one thing an MVP must deliver: a working validation of your solution.

In short: research to accelerate, prioritize to focus, and simplify to ship. Miss any of these, and your MVP becomes just another unfinished v1.

🛠️ How we solve it

Solving the MVP dilemma isn’t about intuition or luck — it’s about applying a disciplined approach to narrowing down scope until only the essentials remain. Here are practices that consistently help:

1. Define the primary problem.

Every MVP starts with a clear hypothesis: “If we solve this problem, users will adopt our solution.” Without that north star, scope decisions are random. Before writing code, align the team on the single problem you’re validating.

2. Identify the core feature.

Most products can be boiled down to one or two functionalities without which users won’t feel any value. These are your non-negotiables. Everything else is optional. If you’re debating between 10 “must-haves,” you don’t have clarity — refine the list until only the features that directly validate your problem remain.

3. Classify the rest: must-have vs. nice-to-have.

Be ruthless: all nice-to-haves stay out of the MVP. If you still end up with more than 5–6 must-haves, you’ve lost focus. Tie each candidate feature back to the core problem. Example: everyone assumes login is mandatory. But is it? For early stages, you can piggyback on packaged auth (Laravel’s built-in auth, Firebase, Supabase) instead of building your own system. Low-code/no-code tools are invaluable here — they buy you weeks of development time.

4. Fake it till you make it.

If a feature isn’t critical but stakeholders want to see it, simulate it. A support system can start as a simple email address. An automated workflow can start as a Google Sheet updated manually. These shortcuts validate demand without sinking dev time. Again, no-code platforms are excellent enablers for this stage.

5. Apply the MVP principle inside features.

Even must-haves can be scoped down. If you need a search function, start with keyword filtering before building advanced full-text search with ranking. If you need analytics, start with one chart, not a full dashboard. An MVP within the MVP ensures you’re always testing the smallest useful slice.

6. Document the scope.

Write down what’s in and what’s out — and why. This isn’t bureaucracy; it’s protection against endless debates. Having a visible “in/out” list makes it clear to the team and stakeholders where the line is drawn, and prevents scope creep disguised as “small changes.”

In practice, these steps won’t silence every disagreement. But they create a common framework for making decisions quickly, keeping the team aligned, and ensuring the MVP remains what it’s supposed to be: the smallest possible product that proves your solution works.

🚀 Next Steps (tomorrow morning)

If you had to start defining your MVP tomorrow, here’s a practical checklist to keep yourself honest:

1. Write down the core problem in one sentence.

   Strip away everything else. If you can’t summarize the hypothesis you’re validating in a single line, your MVP is already in danger of drifting.

2. Draft two lists: IN and OUT.

   • IN: the 1–2 features that directly validate your problem.

   • OUT: everything else. You can revisit later, but for now it’s a clear boundary.

3. Scope down each “IN” feature to its simplest useful version.

   Ask yourself: What’s the smallest implementation that still lets a user experience value? Example: if you need reporting, start with a single export instead of a full analytics dashboard.

Do this exercise in less than an hour with your team or co-founder. The goal isn’t perfection — it’s clarity and alignment.

📎 Primary Resources

1. Henrik Kniberg — “Making Sense of MVP” (Crisp Blog)

   A timeless piece on the difference between a prototype, an MVP, and a full product.

2. Eric Ries — The Lean Startup

   The original reference on MVP thinking, with focus on Build-Measure-Learn loops.

What’s the hardest feature you’ve ever had to cut from an MVP — and why?

Reply to this email and share your story. I’d love to collect real-world cases to feature in future issues.

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!5t

Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!

As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇

Take me to the course

Now, let's dive into today's micro-topic!

In short

🧪 Test-Driven Development (TDD) thrives when feature requirements are clearly defined. In traditional workflows, TDD helps validate known behaviors and ensures safe implementation. But in product-first teams—where solutions are still being explored—this rigid use of TDD might seem limiting or even counterproductive.

🧠 The mindset shift is viewing TDD not just as a tool for testing, but as a tool for design. In exploratory phases, tests help define interfaces, clarify intentions, and provoke team conversations. Even if a feature is discarded, the process improves decision-making and understanding.

🔧 However, using rigorous test suites too early can slow progress or lead to flawed designs. Instead, use lightweight prototype tests during experimentation. These “throwaway” tests act like scaffolding, helping teams learn quickly. Once a promising solution emerges, transition to robust tests and refactor deliberately.

📈 TDD then becomes a two-phase process: sketch with loose tests while exploring, commit to strong design and thorough testing once the idea proves viable. This approach preserves TDD’s value—even when outcomes are uncertain—by aligning test depth with learning stage.

Tell people what you do, and listen what they do

Test-Driven Development shines when requirements are clear—but what happens when they aren’t? What if the only thing we know is the problem, not the solution?

In a traditional setup (aka feature factory mode), developers receive well-formed specs: input goes in, output goes out, write a test, write the code, move on. TDD works great here. It helps validate behavior early and guides implementation safely. But in product-first teams—where you're exploring solutions, not shipping pre-decided features—TDD may feel like a mismatch.

So, should you still use TDD when the future of the feature is uncertain? Yes!

TDD isn’t not just about verification. It’s also about design. Tests aren’t just checks—writing them drives the process of shaping the interface and clarifying intent. Even if the feature gets thrown away tomorrow, you’re using TDD to force conversations and make better decisions today.

During experiments, where you are really just investigating around, you can use looser, throwaway tests. Think of them as learning scaffolding. They help you converge on a direction. Once you hit a promising result—something that meets a user goal or passes an experiment threshold—you know what’s going to stick. That’s when you harden tests and refactor for maintainability.

The key is committing to revisit the code that survives exploration. Refactor mercilessly as soon as an idea proves valuable. That means overcoming the temptation (or pressure) to skip cleanup and jump to the next thing. No design upfront doesn’t mean no design at all—it means deferring intentional design until you’re confident the code has a future.

TDD in this context becomes two-phase: sketch lightly during the explore mode, then shift to deliberate design once you know a feature is here to stay. The test-first cycle remains—but the kind of test and depth of assertion adapt to the stage of learning. TDD is a powerfuul tool—even when the path is unclear—and you should use it to guide throught, not just to verify code.

Until next time—happy coding! 🤓👩‍💻👨‍💻

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!5t

Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!

As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇

Take me to the course

Now, let's dive into today's micro-topic!

In short

💡 Many developers have never experienced high-quality software practices like test-driven development or continuous delivery. The article argues that this isn't because they resist improvement but because they simply don’t know better options exist. Exposure to effective methods is essential — you can't adopt what you've never seen.

🌍 Communities and peer conversations are the true engines of change. Whether it’s through blog posts, Slack messages, meetups, or lunch-and-learns, showing how your team works helps others imagine and apply those patterns. Real-world stories have more persuasive power than abstract best practices.

🧩 Sharing doesn’t require grand gestures. Small contributions — a tweet about rapid PRs, a gist about code review flows, or a short talk — can shift someone’s perspective. These micro-insights, when amplified across networks, help spread healthier and more efficient development cultures.

⚙️ Ultimately, developers who’ve witnessed effective ways of working have a responsibility to speak up. Sharing is what lifts the baseline. Better software isn't handed down — it grows from grassroots knowledge, peer examples, and everyday storytelling.

Tell people what you do, and listen what they do

The way your team works is not just a private matter — it’s a drop in the industry-wide pool.

If you care about clean code, continuous delivery, testability, or healthy workplaces, you need to tell people about it.

Too many developers work in environments where low standards are normalized. They’ve never seen TDD done well. Never seen trunk-based development in action. Never been part of a team that prioritizes quality and flow over ticket throughput.

And that’s a problem — because you can’t adopt what you don’t know exists.

Communities (meetups, Slack groups, conferences, internal guilds, blog posts, newsletters) are where practices propagate. Not by mandate or theory, but by exposure and shared experience.

This is why talking about your way of working matters: it shows what’s possible.

Working in a team where PRs last 2 hours tops? Say it out loud. Have 100% of code in production guarded by feature flags? Tell that story. Moving from monthly releases to daily deploys? Share the journey.

Because when developers hear these things from peers — not just unicorn companies — it becomes credible. And doable.

Awareness is Step Zero. Before change happens, someone needs to know there’s an alternative.

This is also where responsibility kicks in. If you’ve seen better ways of working, and never mention them, you’re not helping shift the baseline.

Software gets better when practices spread. Practices spread when people talk.

You don’t need to run a conference. Just:

• Share your approach in community chats or retrospectives.

• Give a 10-minute lightning talk at a meetup.

• Publish a quick GitHub gist with how your team organises reviews.

• Explain to a junior why your team values small deploys.

These micro-drops of information compound. A better developer culture doesn’t come from top-down initiatives. It grows from shared stories, local examples, practical improvements that others can see and adopt.

So next time someone asks, “How does your team do __?” — take it seriously.

Because your normal might be someone else’s turning point.

Until next time—happy coding! 🤓👩‍💻👨‍💻