PMs discover, shape, and oftentimes prescribe what to build. Engineers figure out how.

This model creates conflict; sometimes cognitive, sometimes emotional. It’s lossy and inefficient, forcing ideas through a cross-functional translation layer that strips away nuance and intent.

It doesn’t have to be this way. Lately, I’ve been experimenting with a different model. One that collapses the gap instead of managing it.

Engineering

I’ve long believed the best engineers wear product and business hats. Shared context creates shared ownership.

Coaching engineers to think like businesspeople and act like PMs has been wildly successful for me, long before GenAI. Now, GenAI commoditizes much of the code and frees engineers for planning and partner management, pulling them out of the weeds and back into creative ownership of outcomes. The payoff is real: shared ownership fuels creativity, and creativity sharpens execution.

But AI isn’t the only lever. Low-code tools built for engineers create a collaborative canvas where engineers and business partners move from discovery to production without a heavy PM handoff.

For example, we recently built a scheduling matchmaker to get patients to the right providers. Instead of writing a PRD and handing it off, the engineer discovered and shaped the edge cases live with the stakeholder. Within days, it was in production with no handoff, no re-translation, no re-interpretation.

Any approach that pulls engineers out of the weeds and onto higher ground is a win.

The industry is shifting. We’re seeing the rise of hybrid product-engineering roles — operators who own outcomes, not just outputs.

Product Management

GenAI is changing things for PMs, too. PMs can now prototype in hours what once took weeks and required engineers. Discovery compresses, iteration accelerates.

But something’s still missing. A prototype isn’t production software. It’s still a prescription handed to engineering.

So the real question becomes: How do we let PMs build in production without sacrificing safety or quality?

My teams have leaned into no-code tools to solve this. Engineers build “legos” for product teams to assemble into real production software.

These legos include frontend components, APIs, workflows, and data pipelines. They expose clean inputs and outputs; PMs wire them together, often accelerated by an AI copilot.

Modern no-code platforms support testing, releasing, monitoring, and debugging. This isn’t a mockup — it runs.

When PMs own the running system, their mindset changes. They stop writing requirements and start thinking in systems.

Collaboration with engineering shifts, too. It moves from delegation to partnership.

The Intersection

When engineers shape like PMs and PMs build like engineers, that’s The Intersection.

Work in the intersection moves faster because each role absorbs part of the other. Autonomy increases, handoffs decrease.

It’s also more collaborative. PMs and engineers still bring specialized skills, but now they overlap enough to share accountability. Engineers depend on PMs for sharper discovery, PMs depend on engineers for durable building blocks.

It’s like a student driver car with two steering wheels, two pedals, and two brakes. Both seats can steer, neither is a passenger.

The traditional dichotomy isn’t going away, and The Intersection model isn’t for everyone. But for teams that want to ship quickly and creatively, The Intersection turns tension into leverage and shared ownership into momentum.

If there’s an amphitheater, don’t argue across it — step into it and make music together.

Probably someone, somewhere. Especially if they almost collided.

Like ships, teams rely on signals to avoid disaster.

A signal is the message others need to hear. It conveys intent and prompts the right reaction.

Teams should talk in signals, not tasks, to steer projects together. Instead of broadcasting what you’re working on, ask: why should others care?

There are plenty of ways to send signals. Here’s a short list:

• I’m starting this because it unblocks X.
• I’m finishing this, now you can move on to Y.
• I want you to weigh in before I continue.
• I value this because it aligns with our goals.

Let me share a few examples of how signals show up at every level, from daily standups to executive direction.

Daily Scrum

I see this ineffective standup ritual at almost every company. Everyone answers the same three questions: What did you do yesterday? What are you doing today? What are your blockers? You know the drill.

Here’s the problem:

• Yesterday’s work isn’t the point — what matters is how others should act on it.
• Today’s plan isn’t the point — what matters is how others should prepare to engage.
• Your blockers aren’t the point — what matters is whether the project’s at risk.

The difference is context. Effective standups put individual work in the context of the team. The speaker conveys intent instead of relying on others to piece it together.

Cut through the noise and send the signal outright:

I’m wrapping up this API endpoint today, so Alice, you’ll be clear to start integrating your part.

The real challenge is knowing what to send, to whom, when, and in what setting. That’s the essence of good collaboration. People who are tuned into what others care about are far more effective. When you think in signals, the rest falls into place.

Product Management

Just as standups reveal how individuals communicate, product management reveals how teams express intent to their partners.

“Product management” is a lot of “expectation management.” Mind the Product puts it well: much of the job is managing how others perceive your intent.

Not all products are inherently good. What you’re building may make people uncomfortable. Your work may expose vulnerabilities, challenge beliefs, or stir up disagreement.

When you know someone may react negatively, think on their terms first. Express your intent clearly and address their concerns before they turn defensive.

Bob, we’re exploring a feature that could raise flags. I’ve outlined how we’ll mitigate the risks and want to walk you through the plan so we’re aligned before moving forward.

Thoughtful expectation management sends a powerful signal. It shows you care about others, you’ve considered their perspective, and you’re in control of the outcome. You can’t always remove the side effects of your intentions, but you can shape how your signals land.

Executive Direction

Whether you’re managing a feature or an organization, the principle is the same: your signals set the tone for how others act.

At an executive level, those signals cascade through the company and ripple out to partners.

A core skills of any executive is painting a vision that others can see and act on.

As Forbes puts it, effective executive communication comes down to aligning:

• Values: I value this, and so should you.
• Tact: I’ve considered how this impacts you.
• Grace: I’m clearly and simply delivering my intent.

Take automation, for example. You want to improve the bottom line, and automating jobs is the answer. Don’t say margins are important; paint the vision of scalability. Acknowledge that people fear job loss, and signal your commitment to progress that benefits both people and the business.

Executive signals travel far. Communicate with empathy and people will follow, even through uncomfortable change.

Beaconing

The best leaders don’t stop at sending signals, they become something more enduring. As John Shedd said, “A ship in harbor is safe, but that is not what ships are built for.”

Zoom out. There’s more to the task you’re working on, the product you’re creating, or the business you’re building. Find the larger purpose — the reason behind the work — and align your signals with the vision.

Good leaders send signals, but great leaders become beacons.

Teams navigate best when people consistently beacon their position, direction, and impact — everyone stops guessing at intent and starts rowing together. And when ships move together, no one drifts in the dark.

It’s been said that software craftsmanship is a dying art. That LLMs are steering software development toward languages that are easily generated. Languages not chosen for their elegance or fitness, but for their compatibility with a model’s training set.

Friends of mine feel it too. Their teams are ditching purpose-built languages like Erlang in favor of generic options like Java. Not because they’re better, but because LLMs can churn them out on command.

Others point out that coding isn’t the bottleneck in product development. I agree. But here’s the uncomfortable truth: businesses are ravenous for software, and even LLMs won’t be enough to feed them.

While the world gluts itself on code, the craftsman waits.

LLMs will flood the industry with net-new code. They’ll subvert human-crafted systems with generative runtimes — inferred, not designed. Sure, we’ll get longer context windows, tighter quantization, and smarter training. Tools will improve. Access will expand.

The trouble is, we treat LLMs like scalpels, but they land like hammers.

In a few years, we’ll be knee-deep in bloated, broken code and deranged prompts praying for salvation. For most, it will be a nightmare to maintain.

As our culture of credit collapses under the weight of this generative mess, the craftsman will still be there, quietly sharpening his tools. Sooner or later, the note will come due on the trade that swapped CPU precision for GPU-powered approximation. And when it does, the craftsman will be prepared to refactor from first principles.

In Part One, I broke down why traditional fixed-scope planning fails, especially in innovation work. In Part Two, I showed you how to plan and execute fixed timeline projects with a real-world example.

Now, let’s look at the results: what actually happens when you run these projects. Over the last six years, I’ve watched this framework succeed, stumble, evolve — and teach me something new every time.

In this final installment, I’ll break down the top three mistakes I’ve made, the key lessons I’ve learned, and the biggest upsides I’ve seen.

At the heart of it all is one concept: emergence.

Emergence

The defining quality of this methodology is emergence. Unlike fixed-scope, where outputs are largely prescribed, the outputs of a fixed timeline project are discovered. Think of it like a jazz performance: there’s a clear theme, but the magic happens in the improvisation.

When you put smart people together with clear outcomes, good things happen. Put the wrong people together, define the wrong outcome, or ignore the common mistakes outlined in this article, and you’re setting the stage for failure.

It takes courage to enable emergence, and hubris to avoid it. Emergent software adapts to reality. But because mistakes are politically unpopular, most leaders optimize for risk reduction instead of great software.

Let’s break down the most common missteps.

Mistake 1: The wrong spec

I’ve chased the perfect spec more times than I’d like to admit, but it doesn’t exist.

The spec’s fidelity should match your team’s maturity, the project’s complexity, your business’s risk tolerance, and stakeholder expectations.

Great teams in collaborative, experimental cultures need very little direction to deliver massive impact. But most teams aren’t operating in that environment. Shape accordingly.

If the team is still nascent, the project risky, or execs are nervous, add more structure to your spec. Don’t expect emergence on day one; work toward it.

Mistake 2: The wrong people

I’ve wasted too many cycles trying to make this process work with people who just weren’t interested in innovation. This method isn’t for everyone. It demands initiative, collaboration, and deep ownership.

Some folks don’t want to wear a product hat. Some prefer tactical, well-scoped work. Some aren’t social or self-directed.

These people will struggle, and they’ll slow the team down.

Coach where you can, reassign where you must. And be honest about whether they’re a fit for this kind of work.

Mistake 3: Poor expectation management

I’ve failed to set the right expectations more times than I’d like to admit. A fixed timeline gives you a clean stopping point, not a finished product. Software is never done.

Always anchor your communication around the problem you’re solving, not the solution you might ship.

When anyone asks, “What exactly are you building?”, the right answer is:

“We have a direction, but the solution is still evolving. I’ll share more as we learn.”

Even better: invite them in. Make them collaborators, not just consumers, of the process.

Getting it right takes more than just avoiding the traps, it takes intention. Here are the principles I rely on to make this process repeatable and resilient.

Tip 1: Cleanups and backlogs

Every project needs a cleanup phase — ~25% of the build length — to handle post-launch bugs, polish, and refactors. Put them on the roadmap. (See the example roadmap from Part Two.)

This is not time for “just one more feature.” Nor is it a catch-all for deferred requests.

Instead:

• Maintain a backlog.
• Cluster related requests into thematic projects.
• Or set aside focused “backlog burn” weeks between larger cycles.

Protect the purpose of each phase: build time for delivery, cleanup for refinement, and backlog time for the rest.

Tip 2: Not a hammer

Don’t force fixed timelines where they just don’t fit.

It won’t work when:

• Leadership doesn’t trust their teams
• The work is pure execution
• The team isn’t ready
• The timelines are too short
• Engineering is measured by output (eg velocity)

Use it when it works, and incrementally address the roadblocks. I’ve managed to use it for most teams, on most projects, since 2019, but YMMV.

Tip 3: Consider it an experiment

Healthy cultures experiment.

Frame fixed timeline projects as one of many ways you’re learning to maximize impact. Share progress, celebrate wins, and be honest about missteps.

This humility builds trust and invites others to help improve the process.

If you follow the tips above, and avoid the traps, the payoff is real. Here are the three biggest upsides I’ve experienced from running fixed timeline projects.

Upside 1: Better outcomes

Executives see market trends. Managers see product-market fit. Implementation teams see what users actually do.

When executives define the why, managers clarify the what, and teams own the how, you close the gap between vision and reality.

Upside 2: Morale

Autonomy fuels morale. It’s that simple.

When teams own the work — not just the execution — they care more, collaborate more, and enjoy it more. That energy compounds.

Upside 3: Strategic planning

Often, the hardest part of software isn’t shipping, it’s knowing whether it worked.

When executives stop micromanaging delivery, they can focus on outcomes. That makes them better leaders, not just better planners.

Conclusion

Fixed timeline projects aren’t a silver bullet, but they are a powerful tool.

They bring structure to chaos. They empower teams to own outcomes. And they shift companies from a culture of output to a culture of impact.

But most of all: they reveal how your team actually works, and how to make it better.

After six years of running fixed timeline projects, I’ve learned this: the best outcomes don’t come from perfect specs or detailed tickets. They come from alignment, clarity, and the freedom to adapt.

If you’re ready to try it, don’t wait for permission. Shape a problem. Set a timeline. Invite your best people. And let the work emerge.

Finally, reach out. I’d love to hear how it’s unfolding for you.

In Part One, I argued that fixed timelines help control runaway scope, lead to better results, and leave teams more satisfied. They shift focus from output to outcomes, and give teams the structure to optimize for impact.

Now let’s get tactical.

In this installment, I’ll show how fixed timelines actually work, using a real, high-stakes project as an example. You’ll see how to define appetite, shape scope, and create a plan that drives results.

In Part Three, I’ll share six years of hard-earned lessons. What worked in the real world, what didn’t, and how to make fixed timelines sustainable.

Optimizing for Impact

Too many companies burn millions of dollars building production-grade software no one wants, not even the company itself.

Not because the final product is wrong, but because the execution is. In innovation work, top-down direction is a trap. Executives over-specify solutions, assuming their broad view equates to deep insight. It doesn’t.

The truth? Most executives aren’t close enough to the product. They miss the nuance in user motivations, edge cases, and constraints. That knowledge lives with the teams building it.

If you want impact, let your teams lead. Executives should define the problem, set the vision, and sketch boundaries of feasibility. Then get out of the way.

“It doesn’t make sense to hire smart people and then tell them what to do.” — Steve Jobs

The rest of this article assumes that culture exists. If your teams aren’t empowered to own solutions, this won’t work. But if they are, it’s time to talk about how to set up fixed timeline projects.

Project Lifecycle

A healthy project lifecycle looks like this:

1. Identify: Executives identify the most critical business problems
2. Propose: Product and exec teams propose actionable problem areas
3. Shape: Product and engineering teams “shape” problems into potential solutions
4. Build: Engineering teams build and measure
5. Measure: Data becomes product insights
6. Learn: Insights become business knowledge

This model pushes problem-solving down to the teams closest to the product and turns learnings into a feedback loop for the business. Executives measure efficacy of their teams by their ability to produce outcomes for the business.

Fixed timelines reinforce this by being outcome-oriented, not output-obsessed. A project might look like:

“We’ll spend 4 weeks trying to reduce [X metric] by [Y%].”

Not:

“Our velocity will be X points.”

Output doesn’t matter if the outcomes aren’t met.

In this article, we’ll focus on steps 1–3: the planning phase. The rest — build and maintain — matter deeply, but they’re not today’s topic.

Plan Slow, Act Fast

Most companies get this backwards: they rush planning and overspend on building.

Planning is cheap. You can sketch wireframes, test ideas, and talk to customers without writing a line of production code. But once you deploy code, write documentation, or set customer expectations, everything gets expensive.

A core tenet of fixed timeline projects is this: building time is fixed, planning time is not. That’s the inverse of most company processes. The goal is to invest enough upfront so that the build phase can move fast and stay focused.

The book How Big Things Get Done drives home this point: plan slow, act fast.

Planning isn’t about locking in every detail, it’s about preparing for uncertainty. Think of it like planning a wedding. The date is fixed, and your job is to avoid disaster. You don’t try to control the weather or micro-manage the DJ’s playlist. Something will go wrong, embrace it.

Let’s look at a real example of a plan that struck the right balance. It has enough structure to move fast, but flexible enough to adapt. We’ll unpack its components in the sections ahead.

A Real Project

Healthcare businesses that offer live clinical services face a familiar problem: patients book appointments but don’t always show up.

They cancel at the last minute or disappear entirely.

That’s bad for business. A provider is still paid to be available, but with no one to treat, the time is lost. The company takes a double hit: a sunk cost and lost revenue.

This project aimed to solve that. The goal: reduce late cancellations and no-shows to improve margins and boost revenue.

The Appetite

This project had three things going for it:

• High impact: 30% of appointments were either late-canceled or missed entirely, double the industry standard. The business was eager to invest.
• Diminishing returns: The industry benchmark was 15%, so gains would get harder the closer we got.
• Uncertainty: It wasn’t clear how to close that gap.

Given the stakes, the shaping team proposed a 4-week appetite for 4 engineers.

The Project Spec

Every project needs a reference doc, a project spec.

It includes the problem statement, success criteria, and a rough plan. It’s the main output of the planning phase, and a prerequisite to start the build. Share it across the business to gather feedback, then finalize it with executive approval.

Here’s a lightly simplified version of the real spec from this project:

Problem: the business is losing revenue from missed appointments. Vision: Patients either show up or cancel in time to rebook their slot. Success Criteria: Reduce late cancellations and no-shows by 10%, as measured by our appointment completion metrics.

Scopes:

• [P0] Send email reminders before appointment
• [P0] Communicate cancellation policy during booking
• [P1] Offer more short-term booking availability
• [P1] Send text reminders on same cadence as email
• [P2] Let patients reschedule or cancel via text
• [P2] Draft a waitlist system plan

Wireframes:

• Reminder emails
• Booking flow UI changes

That’s all a smart, cross-functional team needs to start building, especially when backed by a clear strategy.

The scopes reflect the engineering estimates, but those estimates don’t dictate timelines.

This project started with a problem and everything else flowed from there. Let’s walk through how that happened.

Planning

Planning should be cheap.

A small, senior “shaping team” leads the effort. Their job: create a spec that outlines the problem, success criteria, and a rough plan, without locking in long-term commitments.

The shaping team usually includes one person each from product, engineering, and design. It may include other critical members, and they are encouraged to consult executive sponsors, external partners, customers, or other internal teams.

Ideally, this same group leads the build phase. They’ve built context and trust, they’re best equipped to carry it forward.

The shaping phase is all about answering three questions:

1. What’s our appetite?
2. What’s our success criteria?
3. What’s our rough plan (the scopes)?

Once confidence is high enough we’ve answered the above questions, the project can move onto the roadmap. Shaping doesn’t need to be done to get on the roadmap, just enough momentum to move forward.

Planning is “done” when the team is 80% confident nothing catastrophic will happen. That’s usually enough to start.

To gauge project readiness I like to ask things like:

“How confident are you the team knows how to build this?” “How confident are you these solutions will meet the success criteria?” “How confident are you this meets security and compliance requirements?”

Confidence scores are powerful. They compress diverse intuition into a shared signal. If scores are low, dig deeper. If they’re high, you’re close.

The goal is alignment and readiness, not perfection.

Find Your Appetite

Before you roadmap, you need to set your appetite: how much time, energy, and team bandwidth you’re willing to invest. Executives should help set the appetite because it reflects business priorities and forces tradeoffs.

Two things define appetite:

1. How much time the business is willing to invest
2. The size of the engineering team assigned

Appetite should reflect the value, risk, and clarity of the problem. A high-impact but uncertain opportunity? That might be worth 6 weeks and a full team. A well-defined tweak? Maybe just 2 weeks and a couple engineers.

“We believe this problem is worth solving, and we’re willing to spend this much to solve it.”

Appetite is not scope, it’s the investment boundary. It’s how long the team gets to explore a solution. It should be long enough to make a meaningful impact, but short enough to maintain urgency.

I’ve found 4 weeks is the sweet spot. Longer than that, and it becomes hard to hold a shared picture of the end goal. More than 6 weeks? That’s too uncertain, break it into phases.

Use these as directional levers:

• Increase it for high-value bets, complex integration work, or unproven technical foundations.
• Decrease it for repeatable solutions, vague metrics, or early-stage teams still learning this method.

Team size affects output volume, so match it to the appetite. It should be large enough to succeed, but small enough to avoid coordination drag.

In the next section, I’ll show how this appetite drives the roadmap, and why that makes fixed timeline planning so powerful.

Roadmapping

All you need to roadmap a project is the appetite. If the other elements are still being shaped, that’s okay.

Fixed timeline roadmapping is fast and predictable. Since the length of each project is known up front, you’re just slotting them into the calendar to align with business priorities.

This predictability is what lets senior leaders sleep at night. A roadmap block for a fixed timeline project will last exactly as long as the appetite; no more, no less.

Contrast that with fixed scope projects: roadmap blocks are based on estimates. And as we all know, they’re usually wrong.

Here’s an example roadmap:

A roadmap for fixed timeline work should reflect more than just the build phase. Here’s a typical flow: 1. Discover: Product teams identify problems based on executive direction 2. Shape: Product and engineering teams propose solutions 3. Build: The team commits to building within the fixed timeline 4. Cleanup: Post-launch polish: bugs, refactors, etc.

Including all four phases gives the business visibility into everything the team’s juggling, not just the coding time.

Each phase can vary based on the project:

• Project A: Vague problem; long discovery, moderate shaping, standard build
• Project B: Clear problem and solution; fast discovery and shaping, straightforward build
• Project C: Clear problem, but complex solution; short discovery, long shaping and build

There’s lot of flexibility in roadmapping these projects. As long as the build phases don’t overlap, and depending on the size of your team, things can be shuffled around. Shaping phases can overlap if people can multitask. Discovery can run in the background or spike as needed.

Fixed timeline methodology is outcome-driven, which creates healthy pressure. There’s no rollover. Once time is up, the project ends.

That makes focus critical. Teams must say no to distractions and deprioritize incoming noise. The goal is simple: hit the success criteria within the timebox.

Defining Success Criteria

Success criteria should be grounded in two things:

1. A problem statement – a clear articulation of what’s broken
2. A vision – a picture of what it looks like once it’s fixed

The problem defines what we’re tackling. The vision defines what success looks like.

A sharp problem statement anchors the work in truth. It reflects root cause analysis, invites scrutiny, and aligns with leadership priorities. It also encourages creativity. When the team understands the problem deeply, they can discover better solutions.

“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” — General George S. Patton

Craft your problem and vision statements to be concise and high-signal. Align them with the executive team’s perspective. If there’s friction there, that’s good, it means you’re working toward real alignment.

Once the problem and vision are defined, create success criteria that articulate the measurable outcome you expect if the project works.

Use leading metrics wherever possible; signals that will shift quickly if you’re on the right path. These are what you’ll monitor post-launch to confirm the hypothesis.

Good success criteria:

• Increase sign-up conversion rate by 10% for click-through traffic from Google
• Reduce CI build time by 15% for the frontend test suite
• Increase CES scores by 1 point in the (ecomm) checkout funnel

The criteria are measurable and targeted, and the expected impact is achievable.

Poor success criteria, and why:

• Increase NPS score by 1 point
  • NPS is lagging and easily influenced by unrelated factors
• Users are happier with our UI
  • “Happiness” is vague and not easily measurable
• Reduce customer complaints by 30%
  • Could lead to poor solutions, like making it harder to complain

Once the success criteria are in place, the shaping team can sketch possible solutions and define scopes. But here’s the key:

It’s the implementation team’s job to find the best path from problem to vision.

The success criteria give them the target. The scopes give them a starting point.

Project Scopes

Project scopes are a powerful tool for aligning expectations across the business. They give a clear view into what the shaping team believes will drive the most impact, and invite collaboration before the build begins.

Here’s how to read priority levels: P0: Must-do. Without this, the project fails. P1: Expected to happen, but could be dropped if needed. P2: Nice-to-have. Only happens if time allows.

This priority framework captures the “variable scope” side of fixed timeline work. It signals that the team will aim to complete as much as possible, but can shift focus based on what they learn along the way.

This autonomy is a major driver of team morale and momentum. It gives implementation teams ownership of outcomes, not just task lists.

Scopes strike a balance between direction and flexibility. They show intent while leaving room for interpretation and creativity.

A good scope is actionable but open-ended. For example:

“Send appointment reminders via email”

That scope invites clarifying questions:

“How often should reminders go out?” “Do we send one for every appointment type?”

These questions create opportunities for dialogue, refinement, and better outcomes.

The shaping team should come prepared with context, and stay open to change. If an engineer says,

“Data shows patients respond more to texts than email, should we switch focus?”

The right move is to reconsider the plan, not double down on the spec.

Designs

Designs are helpful, but the fidelity should match the team’s maturity and the complexity of the problem.

In the shaping phase, the goal isn’t to prescribe every detail. It’s to inspire the build, not restrict it.

• If your team struggles to visualize outcomes, high-fidelity designs can serve as strong references.
• If your team has a solid design system and deep domain knowledge, low-fidelity sketches — or even no designs — may be enough.

The real goal is to enable fast collaboration between designers and engineers during the build. Mature teams can prototype in real time, riffing on shared mental models instead of pixel-perfect mockups.

Eventually, teams should evolve past the waterfall rhythm of “design → handoff → build.” When they do, shaping becomes about direction and guardrails, not locked-down UI.

Ticket Creation

Fixed scope projects often begin with a bloated epic full of tickets, each one a pre-defined task handed down from the planning phase.

Fixed timeline projects work differently.

Tickets are created on demand, as the work unfolds. They’re a byproduct, not a starting point.

The goal isn’t to define every task up front. It’s to empower engineers to track and manage their work however they see fit. That might mean:

• Writing tickets to clarify dependencies
• Adding acceptance criteria for QA
• Skipping tickets entirely for low-overhead tasks

Every team is different. Let the ticketing system serve the work, not the other way around.

What Happens Next

This article focused on planning, not building. But when teams plan this way, here’s what you often see, within just a few days of starting:

• Engineers ask important questions, and have space to do it
• Teams rally around the highest-priority scopes
• New members find their role and rhythm
• People start pairing up to move faster
• Prototypes emerge
• Specs evolve

Timeboxing contains scope without killing creativity. Unlike artificial deadlines slapped on fixed-scope projects, fixed timelines give teams control. Teams adapt to hit the goal, not ship everything imaginable.

Managers shift their focus from process micromanagement to collaboration quality. Teams stay creative, aligned, and energized.

In many ways, putting smart people together with a great spec really is like planning a wedding. You set the stage, but some of the best parts are what you didn’t plan.

In the final segment of this series, I’ll share six years worth of lessons from real teams using this process in the wild: patterns, pitfalls, and pivots that made it work. Follow on LinkedIn to catch Part Three!

In this series, I’ll make the case for rethinking how we approach software innovation. In part one, I’ll break down why the industry standard is broken and introduce a new framework. In part two, I’ll show you how to put this framework into action. And in part three, I’ll share insights from six years of applying it with real teams.

The Innovation Spectrum

Product development boils down to two types of work: innovation and execution.

Innovation is ambiguous. The product vision might exist, but it’s often fuzzy, and the path forward is unclear. This work pushes the product into uncharted territory.

Execution is straightforward. The path to completion is clear, and everyone knows what to do. This work builds on existing ideas.

Most projects fall somewhere along the spectrum between these two extremes.

The Industry Standard

The age-old script goes like this: product asks, “how long will this take?” Engineering answers with an estimate. Spoiler alert, that estimate is probably wrong.

This process works well if the work skews heavily toward “execution” because product knows precisely what they want and engineering knows exactly how to get there. The estimates provided are reliable.

Engineering estimates are rarely reliable because most projects don’t lean entirely toward execution. Businesses don’t succeed by reinventing the wheel, and it’s antithetical for an agile process to specify work months or years in advance. So, when engineering provides an estimate it gets padded, or research tickets are created, or they are otherwise just wrong.

Credit: XKCD

Having built dozens of 0→1 products, I’ve learned a hard truth: achieving ±10% accuracy on a six-month estimate requires painstakingly specing every feature, effectively converting innovation into execution. More often than not, this stifles creativity and forces predictability over impact. I’d argue that we should usually prioritize impact when innovating.

When the industry standard is applied to innovation work, everything falls apart. Since product doesn’t know exactly what they want and engineering isn’t quite sure how to get there, those estimates are mostly fiction. Missed deadlines, stressed teams, and frustrated executives asking, “how do we avoid this next time?” Sound familiar?

This recurring failure highlights a deeper issue: the reliance on fixed scope methodologies. Unless work is truly execution, or can be spiked enough to get sufficiently close, all the estimation workarounds are just symptoms of a deeper problem.

The Fallacy of Fixed Scope

A fixed scope process defines how to do the work before you do it. The problem lies in the assumption that we know everything before doing the work. What hubris!

Nobody can predict the future, especially in innovation work where uncertainty is the norm. That’s why we work in “sprints”; to adapt as we go, tweaking the direction with each iteration. But these tweaks are usually variants on the same general direction, the same fixed scope. It’s quite rare that a team embarks on a multi-month epic and has the fortitude to admit they’re on the wrong path.

This is why agile often devolves into “agilefall”. In theory, pivoting every two weeks sounds great, but political, technical, and psychological barriers often get in the way. Teams face resistance to changing roadmaps, the pain of undoing recent work, and the burden of sunk cost fallacies, shame, and overconfidence. It leaves them struggling to chart the path forward.

The issue compounds when influential stakeholders — executives, product managers, engineers, and business partners — cling to their own idea of “done”. This rigidity drags out timelines and stalls delivery until all expectations are met.

At its worst, fixed scope feels prescriptive and strips intelligent engineers of their creativity. Product dictates the solution, and engineering is expected to follow orders, leaving little room to challenge assumptions. Even when some engineers are included early in the planning process, involving the entire team is often impractical. A healthy process empowers all engineers to critically evaluate product decisions and push back when needed, fostering collaboration and driving better outcomes.

So, how do we overcome these obstacles and achieve true agility for maximum impact? The solution is to adopt fixed timelines with variable scope.

The Case for Fixed Timelines

If everyone humbly acknowledges that we don’t know precisely what we want to build and commit to exploring our way into a solution, then we can more readily leverage other approaches.

A fixed timeline process involves specifying a maximum timeframe for a project, like four weeks, and allowing the scope to vary within that period. It ensures teams spend no more than four weeks on a project, while keeping the outputs flexible.

“The enemy of art is the absence of limitations.” — Orson Welles

Fixed timelines flip the script. Instead of asking, “how long will X take?” project planners reframe the question to, “how much time are we willing to invest in X?” This shift sparks collaboration, creativity, and ruthless prioritization by challenging the implementation team to deliver the best possible version of X within the allotted timeframe.

Innovation work inherently risks runaway scope, but time-boxing effectively contains it. Instead of eliminating ambiguity upfront — with spikes or exhaustive planning — fixed timelines embrace it, ensuring teams can adapt within clear boundaries.

I first discovered this approach in the Shape Up book. It offers many valuable insights, but the most salient takeaway is the concept of a fixed timeline.

Over the years, I’ve leveraged this framework for innovation projects with measured success. I’ve adapted the book’s principles to handle the complexity of healthcare, streamline processes, and maximize collaboration. I’ve shipped major overhauls to core infrastructure, launched brand new products, and built complex integrations. All on a fixed timeline. The result? Happier teams, better outcomes, and improved operational efficiency.

Benefits

When used appropriately, this paradigm has many benefits. In Part Three, I’ll expound on the benefits and the challenges. Here’s a snapshot of the upside:

• For product managers: Roadmaps become easier to plan with timelines fixed to a pre-defined length, reducing the need for day-to-day project management and freeing time for upstream activities like market discovery.
• For engineering managers: Teams become more collaborative because everyone knows what success looks like and discusses tradeoffs about the best use of their time.
• For engineers: Engineers want to solve business problems, not just implement prescribed solutions. Empowering them to get creative leads to greater fulfillment and better results.
• For senior leaders: Leaders gain more control over roadmaps by defining project length themselves rather than relying on engineering estimates.
• For executives: Executives spend less time worrying about project minutiae (the “how”) and more time articulating the vision (the “why”).
• For everyone: Power and influence over project completion shift to the people best equipped to deliver measurable outcomes: the implementation team.

In Part Two: I’ll show you exactly how to design fixed-timeline projects for success and transform your team’s approach to innovation. Follow on LinkedIn for updates!