Project Engine

Most of product work is figuring out what you should build. And what you build comes in the form of projects. A project is a defined unit of work with clear start and end dates. This discrete unit of work is a currency. It holds perceived value (like property), and is selected as a bet to deliver a return on the investment of time and energy to complete the work. A project is centered on a problem. Reframed, the problem becomes an opportunity. If addressed correctly and on time, value is created in the form of more revenue and new customers.

That’s the basic premise.

Signals emerge and point you at a problem you feel, with enough certainty, will yield results. And the better your intuition, the better your chance of success. But luck is also involved. Oh, and timing. And no matter what, you’re still guessing up until you ship something and get feedback—primarily people paying you. So the faster the iteration, the better.

If projects are this important, then you should get really good at selecting, delivering, and reviewing projects. In Design Engineering, I discuss the Project Engine as a simple five-step process for integrated teams to execute:

1. Align: Align on the problem, team, and the boundaries (constraints).
2. Clarify: Develop a shared, first-principles understanding of the core problem.
3. Model: Explore solutions, sketch flows, and converge on a viable direction.
4. Build: Deliver the solution through iterative forging and refining.
5. Learn: Measure impact and feed insights back into the system.

The deviation from typical software practices is that the delivery process (steps 2-4) is completed in a single time box. The work is done with an integrated team of design, engineering, and strategy. They solve the problem end-to-end on a small budget—no hand-offs, no waterfall, no missing context.

They start together, stay together, and deliver the final product together.

I’d like to expand upon the seeds of the Project Engine shared in Design Engineering. I will define the full project lifecycle, and share principles and practices to help your team work together as a single unstoppable force. This is a new type of process—one aligned with modern software development realities, real-world environments, and AI as emerging technology.

This idea is called the Project Engine, which lives in the Clarity Current of the Claritorium and Value Creation of Equilio.

The three pillars are:

1. Project Selection: What do we work on?
2. Project Delivery: How do we deliver it?
3. Project Review: What did we learn?

Project Selection

Project Selection starts with discussion. Your team should engage in healthy debate about what to work on, who should work on it, and how much time you need. There’s no silver bullet or priority matrix to save you from the messy conversations.That’s the work. And if you want to place the right bets, you need to monitor all inputs: team channels, emails, issues, usage data, customer calls, support tickets, business objectives. Everything adds to the fidelity of knowledge. But you need to know how to translate the inputs and integrate them into your selection process. Because there will always be more things to do than resources to do them. That’s the challenge, but it’s also the responsibility and the opportunity.

You need to align on three things:

1. The intention of the work.
2. The team who will work on it.
3. The constraints you will work within.

The output of Project Selection is a bet.

You decide on:

• The constraints in the form of the clearly framed problem and time budget.
• The resources in terms of the team responsible for delivering the solution.

Intention

The reason figuring out what to work on is so difficult is due to how many problems there are—a seemingly endless supply, in fact. You can’t solve all the problems. But you can focus on the most critical ones you believe will return the most value for your customers and your business. In Understanding Value, Joshua Arnold defines a framework for thinking about value that I quite like:

1. Increase Revenue: When you increase sales to new or existing customers.
2. Protect Revenue: When you make incremental updates to sustain revenue.
3. Reduce Costs: When you reduce costs you’re incurring to lower margins.
4. Avoid Costs: When you make improvements to sustain current costs.

When it comes to value, you’re increasing or sustaining. Both options matter. And they are part of the Product Equilibrium. When you think about what problems to focus on, use this lens to focus your intentions. Because that’s what this stage is about: intention. You create a frame of the problem, what value you expect, and why now is the time to solve it.

The intention is made of the:

1. Problem Frame: The narrow slice of a problem you’re focusing on addressing.
2. Expected Value: The actual value you expect in return for the solved problem.
3. Clear Urgency: Why it’s important to solve this problem now versus later.

Problem Frame

Never underestimate the human tendency to increase complexity. The more you talk about something, the larger the scope grows.

Problems are no different.

You need to focus your energy on excavating the root problem. This is often called “root cause analysis,” where you keep digging until you identify the real problem (the root). Most of my energy is spent reducing, simplifying, and constraining. You need to zero in on the smallest problem area. Less surface area, less unknowns, assumptions, and risks.

The Problem Frame is a clear articulation of the thinnest slice of the problem you intend to solve. It’s expressed in a way that no one on the team could misunderstand or misinterpret.

Instead of:

Users have trouble signing in.

Say something like:

Users don’t remember what authentication method they use when signing in, forcing them into endless password resets, open support tickets, and unnecessary engineering time to investigate.

The first statement is a shallow representation of the problem. It invites confusion.

The second statement is a clear articulation of the problem. It invites clarity.

Or reframed as a question:

How might we help users remember which authentication method they used when signing in?

Why a question? Because it invites divergent thinking as diverse solutions. You always go wide before you go deep.

And, if you want to abstract your thinking even further, you can simplify the question:

How might we help users sign in?

The right Problem Frame helps you diverge and then converge on possibilities.

Expected Value

If you write your Problem Frame well, the Expected Value follows naturally. The value in solving the problem is inherent to a clear expression of the problem. It’s clear, specific, and value-focused. Using the example we started with in the Problem Frame, we can reverse-engineer the value out of it:

1. Frustrated users dealing with password resets don’t convert or churn, so avoiding this protects revenue.
2. An increase in unnecessary emails is an expense with most email services, so it also avoids costs when we fix this.
3. Engineers and support staff cost money, so avoiding the extra overhead is another way to avoid costs.

Solving this problem is focused on sustaining instead of increasing value. That’s okay. Some of the most valuable product work is about quality refinement vs. value creation.

We can define success metrics as the quantitative measure of expected value:

1. Lower Churn Rate
2. Lower Email Costs
3. Less Support Tickets

These are all measurements. Combining qualitative and quantitative metrics creates a well-rounded view of the expected value. And tying the problem to clear metrics makes it easier to compare with other project options.

Clear Urgency

When you’re looking at a list of things to do, project titles and descriptions don’t provide much to bet on. You need the Problem Frame and Expected Value. That helps. But you also need to know why right now. Why can’t we just fix this problem later? What’s the urgency?

Clear Urgency answers those questions.

It tells you:

1. Why the problem is so urgent to solve now.
2. Why it’s more urgent than other problems.
3. What happens if you don’t solve it.

Let’s answer these for our example:

1. Why now? Authentication is the gateway to the product. Issues signing in rapidly erode trust while engineering and support efforts compound and get worse over time.
2. Why this? None of the features in the product matter if users can’t sign in. And the erosion of trust has deeper negative consequences when there are alternatives.
3. What if? Trust continues to erode as the engineering and support teams spend more time, energy, and money to chase downstream issues vs. solving upstream.

Team

Next, you need to assemble the team. This is an area ripe for innovation. There are AI coding agents, tools, and new ways to break down the traditional barriers between design, engineering, and strategy. If you align with the idea of Product Builders and Bamboo Teams, then this is a natural progression. But there’s also a natural separation of types of projects that require different team compositions.

To assemble the project team, you need a:

1. Team Type: Whether it’s an integrated, engineering, or copilot team.
2. Project Lead: Who is responsible for tracking work and communicating progress.
3. Project Sponsor: Who is owning and championing the problem to give feedback.

Team Type

While experimenting with this approach, I found three common types of project teams:

1. Integrated: A single team with one strategist, one designer, one engineer.
2. Engineering: One engineer working on largely technical or back-end changes.
3. Copilot: One strategist and one designer working with a coding agent iteratively.

What’s interesting here is the combinations you can create. Some projects start as an Engineering Project. One engineer creates a working prototype, and then a strategist and/or designer comes in to refine, rounding out the Integrated Team. This follows the process of Reverse Refinement. Other projects make sense as a Copilot Team that later adds engineering to refine (or not). And the trickiest of projects leverage an Integrated Team from the start. You can play with what works. This is heavily dependent on your team. What matters is thinking about the team you need to address the problem at hand.

To illustrate, I’ll give you an example of a project we just shipped in this structure.

We just released a redesigned version of settings for our AI chat. I initially sketched some ideas, and then worked with two designers in Figma—a Copilot Team. We created mockups and exchanged feedback. I knew when to draw the line and move to code. I gave a local AI coding agent the mockups and an extensive prompt. It gave me a first iteration, which I refined through a mix of prompting and writing the code myself. It was collaborative, iterative, and quite fast. I opened a Pull Request with a deploy URL for the team to test. We moved from design to working code rapidly. Then we iterated in the live environment until it was ready.

We originally planned to include saving settings, but it was too much scope, so we decided to defer it to a separate release. Also, that work requires database and API updates, so we need to bring an engineer into the project. While yes, I am an engineer, there’s an extensive back-end that requires dedicated engineering focus. So we decided to track this new project as an Integrated Team. Another alternative would be to stand up the back-end as a one-week Engineering Project, and then come back in as a Copilot Team to execute on the front-end. These project types create flexibility and optionality, which is especially useful for small teams. But the best way to approach the work is with integration.

Integrated

This team is your fully staffed team. Each discipline—design, engineering, strategy—merge into a single team. This is the representation of the Product Builder, assembled as a collective. You put one of each discipline on a core problem to solve it from conception to creation. They work autonomously and make decisions to deliver the work on time and with quality. Use this team on the hardest problems that contain the most unknowns, assumptions, and risks.

Engineering

You can staff 1-2 engineers on a project when it’s back-end work, infrastructure, or leverages pre-existing components in your product. I find it helpful to isolate projects as engineering projects when there’s a valuable output to users. For example, a database migration that improves response times; or an indexing project that increases search results; or an improvement to the developer experience. The last example is exactly what Accelerating is.

Copilot

This is a new team ideal for the age of AI. LLMs and agentic coding technology is getting better at a rapid pace. I’m shipping 2-3x more code leveraging these tools. Apply that consistently across a small engineering team, and you create an outsized impact in output. But I also care deeply about intuition. It’s a core part of the Equilio philosophy. You can’t effectively use AI to write code if you don’t know how to use your intuition and critical thinking to review its output. I treat it like a junior developer, although it’s rapidly advancing to the level of mid and senior. Using Claude Opus 4.5 and prompt engineering, I’m seeing incredible results. Fun times! And when you form a Copilot Team of a strategist and designer, you can deliver a lot of valuable features in rapid succession. This is still an experiment, but I’m loving the results.

Project Lead

Every project has one Project Lead. They are responsible for making sure all the work is tracked and progress is updated. Each project update happens on Fridays and requires a written update and setting the status of the project (on track, off track, at risk). You can even embed a video demo in the update.

The lead can be a strategist, designer, or engineer. When I’m on a project, I typically fill this role, but it can be anyone on the team. It’s good to have everyone experience the role and learn the ropes to diversify skillsets. When everyone learns that leadership is an activity, not a role, you create a well-rounded team of self-starters and intuitive builders.

Project Sponsor

The Project Sponsor is similar to the “product owner” role in traditional product processes, but with added nuance:

• It’s a stakeholder who champions the idea.
• They serve as the subject-matter expert.
• They give feedback and watch progress.

The purpose of the role is to have someone outside the project team who needs direct input into the work. They know the problem well, and can help make key decisions when the scope changes during delivery. When the team kicks off the project, they join the session to share context. And then they’re available to give feedback and watch the evolution of work, avoiding any surprises in the finished product.

Constraints

Constraints are a paradox when it comes to creative work. If the creative process is meant to be messy and unstructured, wouldn’t constraints negatively impact the output?

No; quite the opposite, actually.

Constraints breed creativity. When you’re forced to work within specific boundaries, you have to make decisions. Those decisions are trade-offs, and they shape the outcome.

Think about the iPhone. It was the first mobile device without a physical keyboard. They made the choice to apply that constraint, and it forced the team, through rapid iteration, to design the touchscreen keyboard we all use so naturally today. Paradoxically, when you have to think inside a box of constraints, you think outside the box with creative solutions.

The constraints for Project Selection are:

1. Time Budget: How much time you’re willing to spend to solve the problem.
2. Project Timeline: The start and end dates of the project—the timeline of work.
3. Scope Boundaries: Any specific callouts or areas to avoid in the work.

Time Budget

Shape Up calls this the appetite. It’s a budget for the work. Instead of lying to yourself with estimates, you get real and define how much time you’re willing to spend on the solution.

The timeframe depends on your organization’s appetite for bets. 1-4 weeks is what I’m using today so it maps to monthly releases. It fits the cadence and speed of our company and market. You should define what works for you.

If you fix the time, then you need to vary the scope of the solution. That’s the key.

Project Timeline

The timeline is the start and end dates for the work. This is what you lay out on a timeline to understand the schedule and how resources will move between projects and other work.

Scope Boundaries

When you define the problem, clear risks surface. These are the areas you want to avoid because they derail the timeline. Your senior engineers will spot the risk areas immediately. You should seek these out and apply the right constraints as part of the selection process.

Project Delivery

Once you select the project with all the attributes defined, you move into the delivery process. This is when the real work begins. You move from discussion to creation.

Project Delivery is when your chosen team comes together to build the end product.

You can create the Intent Brief in Project Selection, or you can build it through the stages of delivery. Remember, an integrated team works the problem end-to-end. That means they clarify the problem, model a solution, and build it iteratively as a single, unified team across the disciplines. It’s a Product Builder in team form.

The team comes together on the first day of the project to make sure they understand the scope of work. Context is shared freely. Then they rely on the Product Heartbeat to:

• Sync at the beginning of the week.
• Collaborate and pair daily.
• Review the work at the end of the week.

Project Delivery is focused on:

1. Project Integration: How the team moves between clarifying the problem, modeling the solution, and building the product.
2. Project Status: How the team communicates the state of the project.
3. Project Breakpoints: How the team makes decisions and makes trade-offs to deliver the work on time.

Project Integration

Project Integration has three stages:

1. Clarify: The team makes sure there’s complete clarity on the problem.
2. Model: The problem is modeled as low-fidelity solutions with sketching and then even prototyping in code.
3. Build: The solution is built iteratively, tested by the entire team, and improved in very tight value iterations.

Clarify

Even though the problem is framed during Project Selection, the team should always wrestle with the language and make sure there’s complete clarity on it. They put pen to paper and articulate it in the Intent Brief so it can be socialized and improved. Words externalize thinking into a shared context for the team to debate.

Model

When modeling the solution, the team works with low-fidelity artifacts to speed up the process of iteration. This is done collectively in an integrated team, but the engineer should also be in the code early. Your goal should always be to get into the final context as quickly as possible. Write code, prototype, and get a feel for the live product. Use tools like Figma when you need to diverge and think with less restrictions, but don’t get too far away from the code. It’s how you’ll bring the work to life. It ends there. And that’s why I love designing in the browser and working backwards to refine. You see the immediate constraints in front of you. There’s no translation because it happens in real time.

Part of the Intent Brief covers the shapes of the work. This is where the team can think about and define how the work will ship. If the time budget is four weeks, how will they release the work iteratively? What are the value iterations?

Build

Building is when you’re working against the Intent Brief to ship the individual scopes of work. If the project is the map, then you’re drawing lines in sections to define the ship-able parts of the map. Doing so creates progress, builds momentum, and highlights the tension points early. You build in vertical slices of real value. The front-end and the back-end meld together in a single unit of value.

On an Integrated Team, the designer works closely with the engineer to refine the details. They can even help with micro-interactions and leveling up the quality. The strategist is defining key metrics, the release strategy, and working on artifacts to share with sales, marketing, and other teams. But the team still rows together against one desired outcome.

Project Status

During the delivery process, the Project Lead is responsible for communicating status:

1. Stage: The stage and sub-stage of delivery.
2. Risk: On track, off track, at risk.
3. Checkpoint: Current week and description.

Stage

The stage is the Progress Resolution. It tells you where the work stands:

1. Problem Definition: You know what you’re solving and why you’re solving it.
2. Solution Definition: You know how you’re going to solve it and deliver value.
3. Build Definition: You see the work in a tangible form in the real environment.

The stages map against the integration steps of clarify, model, and build. Knowing where you are helps orient the work and the team. And it’s an important part of communicating progress to external stakeholders.

Risk

At any point, the work is either:

1. On track and on schedule for delivery.
2. Off track and needs recovery.
3. At risk and needs support.

Knowing the risk level early and often helps course-correct a project before it’s too late. If it’s off track or at risk, additional support can come in to help clear roadblocks. You need to slow down to speed up. Discuss the work. Find ways to reduce scope and increase speed. It may feel unproductive to stop the build, especially when you’re behind. But some of my most productive moments during projects came when we discussed the work as a team, and found solutions to get back on track.

Checkpoint

The checkpoint is simply the current state of the work as point-in-time information. Knowing what week you’re in seems trivial, but it’s an important orientation device when you’re building. Paired with the stage and risk, you always know the given status of the work. The checkpoint also adds a one-sentence summary of the current state of the project.

It’s short, simple, and effective.

Example:

Week 2/4: Build in progress and working on the first iteration.

Project Breakpoints

Responsive Web Design (RWD) is an approach to web development where you adapt the layout to the user’s device, screen size, and orientation. Ethan Marcotte coined the term in his 2011 article in A List Apart. I still vividly remember reading (and re-reading) the article when it came out. It was groundbreaking—a new way to think about making websites. Before this technique was popularized, you would often maintain separate codebases and domains for the desktop and mobile versions of a single website. Now, you could author one codebase that would responsively adapt to a wide range of devices and screen sizes. The layout shifts at specific points are called “breakpoints.” Most commonly, you define breakpoints at standard device sizes like desktop, tablet, and mobile sizes.

In much the same way, there are breakpoints during a project where you make important changes to maintain the timeline.

I call these Project Breakpoints, and they come in three flavors:

1. Scope Breakpoints: When you make changes to the project’s scope.
2. Feasibility Breakpoints: When you make changes to the technical details.
3. Value Breakpoints: When you make changes to what and when you deliver.

Scope is what fits.

Feasibility is what’s possible.

Value is what matters most.

Scope Breakpoints

In order to deliver work on time, you have to make trade-offs. No matter how much planning you do ahead of time, there will always be unknowns in the work once you start writing code. To guard against that, you have to lean into the unknowns and make scope changes in real-time. In almost every project of reasonable size, you hit these points. Lean into the collective intuition of the team to discuss and find pathways for progress. The best way to approach this is through small, weekly slices of work. Take the 4-week project and deliver it in smaller weekly iterations. Use it, talk about it, and think about how to reduce the scope and complexity of work.

A common example: When you focus on edge cases that only affect a small fraction of users. The Scope Breakpoint is deciding to cut that work and work on it after initial release.

Feasibility Breakpoints

The Feasibility Breakpoints are closely related to scope, but focused on technical aspects. You change the technical details to address risks and to reduce the complexity of work. A simpler scope reduces the surface area of change; dealing with technical feasibility reduces the complexity of change. Each of the breakpoints is focused on simplification, reduction, and improvement. When you hit a technical limitation (the breakpoint), you establish a new constraint to work within. It’s a new frame for the work. If you fight it, you will lose. Treat it as another creative constraint to unlock innovative solutions.

A common example: When you design a custom component, but see technical complexity you can reduce by reusing an existing component or filling in with a third-party component.

Value Breakpoints

The Value Breakpoints focus on the product value delivered to the user. An intimate knowledge of how your customers use your product helps draw the right lines. Most products are built around workflows, and the projects you work on are meant to improve the workflows. Often, though, you move outside the core flow and start making changes with a lower impact. These breakpoints occur when you reign it back in, refocusing on the most high-leverage use-cases where your product can deliver the most value per effort.

A common example: When you spend too much time on an area with very low usage that’s outside the core flow. You decide to set a breakpoint and shift focus to the primary goal.

Project Review

Software is continuous—an endless pursuit of continuous improvement. Once you complete Project Delivery, you move into the Project Review phase. I apply the same principles to a review of any type, whether it’s reviewing a project with your team or your productivity over the past week. In Steady Beats, I talk about my process for Weekly Reviews:

1. Wins: List out all the wins.
2. Learnings: List out 3 learnings.
3. Takeaways: List out 3 takeaways.

The Project Review is the same:

1. What went well? What did you deliver?
2. What changed? What did you learn?
3. What’s next? How can you improve?

Create the Impact Brief and detail everything you shipped, what you changed, and what you’re working on next. Keep it simple, repeatable, and consistent for each project.

Learning in Motion

I like to learn by doing. Trial by fire has always been my main mode of learning. When I create a new process, I build it in motion, capture feedback, and iterate in real-time.

This way of thinking aligns with Equilio:

Use intuition to guide you.

Use integration to ground you.

Use iteration to improve the outcome.

The Project Engine is a new way of working. It acknowledges what came before it, but looks at the act of building software in a new and refreshing way. It replaces rigid frameworks with collective intuition; awkward hand-offs with deep integration; endless ceremony with rapid iteration. You don’t waste time with simulations, assumptions, and predictions. You do the work, as a team, and move from conception to creation with haste. You deliver, learn, and adapt to the environment.

It all begins with the right project.