How we use ‘shaping’ to accelerate time to market

Companies have been trying to “hack” the product development process for decades (potentially even centuries if we include non-digital products), only to run into unexpected issues that essentially nullify whatever time- and money-saving methodology they were using. Exit this particular strategy—on to the next one… 

At Mixpanel, just like at any other company, we’re always trying to improve how we do things to avoid backsteps and wasted work. 

To that end, in 2020, we started using a process called “shaping”—a project planning strategy from Shape Up, a book by project management company Basecamp—that has already paid dividends for our product development and looks like a keeper. 

The overall idea is this:

Each six-week product development cycle should end with something complete (meaning deployed) and shipped end-to-end. Projects that do not finish within their six-week cycle are canceled by default and do not get extensions.

We’re not saying shaping is the end-all be-all, but it’s worked for us, so maybe it will work for you.

The problems that led us to adopt shaping

Our team does retrospectives of finished projects to help improve our execution process and noticed some consistent areas for improvement, even in projects considered successful. 

These areas included:

1. Projects dragged on and it was unclear when we could or should move on to something else.
2. Big, important questions about the customer experience and project scope would surface when we were deep into implementation, and finding answers to these questions would stall work and change plans.
3. We would change our minds about our goals months into implementation, wasting both time on the original implementation and time trying to clean up unused stuff we had built.

We realized we needed a better way to do things and to manage our time and priorities. 

What exactly is shaping?

Shaping is a set of tools and techniques to define projects, address unknowns, and increase collaboration and engagement within your team.

In adopting the ideas of Shape Up, we feel like we’ve addressed key product development issues described above and now spend less time bogged down by long-tail work on old “finished” projects, have more confidence in what we are doing, and waste less time on dead-end projects. At the same time, we haven’t lost the parts of our process we felt like we were doing well.

The extreme TLDR for shaping is: 

1. Scope down a project until you have something that delivers value within six weeks. (Test: If you had to stop working on this at week six, would it have been worth it?)
2. Execute on this plan for six weeks at most. 
3. Run a thorough retrospective at the six-week mark and decide whether to continue investing in it.
4. Repeat.

Of course, the whole point of shaping is to adapt and apply it to your own products and teams, and a little further down we dive into how we use shaping at Mixpanel. But first, let’s discuss this whole six-week thing. 

How we use shaping to accelerate product development 

Here’s a bird’s-eye-view of where shaping fits into our overall product development process:

Shaping exists within the greater product development lifecycle that starts with a high-level vision and ends with implementation. It’s the second stage and the one that comes between vision and design. 

We can break the above illustrated product development process down into five stages: explore, shape, build, reflect, cooldown. 

Here’s how we approach each stage. 

1. Explore

The first step in the exploration phase is to answer: What problem are we solving and how much appetite for risk (i.e., person-months) are we willing to put in? The answer to this question bounds the solution space and forces the right tradeoffs up front. If we don’t know the answer to this question, that implies we must scope-hammer the problem to its essence—something simple and clear enough that the answer to those questions are obvious. This leads to boring, simple features that are incredibly useful.

The second step is to write all of this down. Written, long-form communication is key to building and sharing high-quality ideas and it’s worth over-investing in this step (write, re-write, re-write again) until you have something polished that perfectly aligns the team. Writing is cheap and easy to undo, while building is expensive and hard to undo. Do not start building until you’re confident in your pitch end-to-end.

We’ll write several iterations of the press release and documentation and are totally okay with throwing them out if the approach doesn’t make sense. We show the plan to key stakeholders (support, sales, service owners) to identify as many risks as possible (e.g., might be too complex to be valuable, might not solve as many gaps as we hope). If risks are high, we try adjusting the plan to control for risks or start over with a different approach. Gut-checking technical feasibility is good, but we want to avoid anchoring bias and getting into the implementation details at this stage.

In this step, we often decide not to solve the problem right now because we cannot come up with a solution we are confident in. Projects are like poker bets. It’s normal and healthy to fold 80% of the time.

2. Shape

After exploration, we move on to the actual shaping. 

Here we ask ourselves: What would we build if we only had two, four, or six weeks to solve this problem? And we do this with the team we plan to staff to build it. In particular, we look for unanswered technical questions that may blow up scope and add answers to the documentation we developed in step 1 if these answers affect customer experience.

We recognize that for larger initiatives, there may be no feasible solution in under six weeks. In this case, we return to the “Explore” step with the goal of shrinking the scope of the problem (i.e., change the press release and documentation, promise less functionality, and document caveats for edge cases). The larger project should be part of the vision we are working towards, but it is an aspiration, not a plan. We are putting our planning effort into providing end-to-end value in the next six weeks of implementation.

Note that we take hitting the six-week goal seriously as part of designing the solution. Before adopting shaping, we would estimate how long work would take as a sanity check and to pick milestones, but those estimates had minimal value as the plan was generally already decided and/or too vague for the estimates to be accurate in the long term. Estimates never changed the overall plan. In contrast: Now we reduce project scope until our estimate says we are confident we can provide value in under six weeks.

3. Build

Next, we spend six weeks building the thing we decided to build. If we shaped correctly, there should be no need to make major adjustments or additions to the plan. Since we are confident the project will end in six weeks, we feel okay not dealing with most interruptions until the project is finished, allowing for focus.

4. Reflect

After building, we do a retrospective to speak openly about what could improve and avoid repeating mistakes. If we thought the six weeks of work was part of a larger project, we can reassess that now by putting that project back through the exploration process. We do not automatically keep working on the same project past the original six-week plan.

5. Cooldown

Finally, in the cooldown phase, our engineers will take two to three weeks to work on self-directed tasks (bugs, service ownership, cleanup, experiments, etc). This phase is absolutely critical. Remember: It’s okay for engineers to be “idle.” (All together now! “It’s okay for engineers to be idle.”) Because good engineers are never really idle. They’ll find and fix bugs, improve tooling, level-up their services, think deeply about technical direction, or do other things that they can’t do when staffed on some time-sensitive project. If you don’t trust your engineers to sit “idle,” improve your hiring process.

This frees up the shapers (i.e., product development leads) to avoid situations like:

• Spending three weeks shaping a possible bet
• Realizing towards the end that it’s not worth doing
• Feeling anxious that their team is sitting idle and randomly whipping up a poorly-thought-out project for standup the next day

It’s much better to build nothing than build the wrong thing. 

At the end of shaping, your team will spend six weeks executing on the plan and, if you do a good job, only another six weeks maintaining it. Plus, you’ll have to document, market, and sell it. It’s only worth doing if you’re confident, and the opportunity cost of “idle time” is much lower than you think.

The six-week element, explained

Since it’s such a key part of shaping and also the part you will most likely be questioning—and potentially calling out as arbitrary or unrealistic—let’s dig into the six-week element a little more and answer the questions you likely have around that part. 

Why enforce a strict time box?

A strict time box is a valuable constraint to help reduce complexity and risk during the design process (see “appetites, not estimates“).

A small, fixed time window allows teams to regularly re-evaluate and react to new information (every six weeks) while never having it be too expensive to finish or revert work that has been started. If you realize four weeks into a project that the ROI will not be as high as you thought, and you do not want to continue your investment with a second six-week cycle, you can still take the remaining two weeks to finish and end up in a maintainable state you had planned ahead for. That’s better than being halfway through a 12-week project, scrambling to come up with a new endpoint, and leaving a half-finished project with lots of new technical debt.

If a project does not deliver the expected results, then you’ve wasted six weeks of work at most if you completely scrap it.

How is this different from each six-week cycle being a milestone?

Milestones assume projects continue to the next milestone by default, while the six-week cycle assumes projects are completed at the end of six weeks by default and any work thereafter needs to compete with the priorities for the next six-week cycle.

The six-week cycle is a forcing function to organize work into completable chunks, do simpler high-value things first, and uncover unknowns early. It controls for the risk that in six weeks you will have new information and any “milestone two” you might previously have imagined may no longer be the highest priority or the right approach. A milestone model, by contrast, commits (whether intentionally or not) to a long-term plan that you are unlikely to follow through on, and when you fail to follow through you end up invalidating assumptions you made in earlier milestones that affect the quality of your implementation.

For example, a valid plan for developing M1 might be “build the complex backend first, expose a simple version in the UI in M2, expose a more complex version in M3” or “get features X, Y, and Z all working, whatever it takes, we’ll clean up any technical debt in M2 or M3 to become ‘GA ready.'” Both of these plans carry several risks with big potential downsides:

• What if you show the feature to customers and it turns out they didn’t need all these complex options?
• What if you’re well into M3 but realize this project is more work than you were originally willing to put into solving this problem?
• What if you’ve started showing the feature to customers but it isn’t providing the value you originally assumed it would and you want to scale back your investment?
• What if you learn of new, higher-value work you could be doing instead?

In these cases, you end up leaving overly-complex, half-finished work behind that becomes a drain on your engineering resources going forward.

The six-week cycle is meant to limit the risk and potential downside of these issues by discouraging the addition of unnecessary complexity or technical debt for the next six weeks under the assumption that you know what you’ll be working on in three months well enough to be sure it will get fixed.

What if my goal will take more than six weeks to achieve?

In order to properly de-risk this possibility before staffing it, you should identify a six-week project that will move you closer to your goal and provide validation of your general approach. You might want to try shaping multiple different sub-pieces to understand which appears to be the lowest risk for the highest ROI.

What about interrupts or delays?

Once a project is staffed, all members of the team should work uninterrupted only on that project. There are many things that can get in the way of this, but Shape Up addresses a lot of common ones:

• Prior projects should have been designed to end after six weeks and there should be no follow-up work from past projects other than unexpected bug reports. If the project was not done, then it was canceled, so there should be no overflow work from previous projects.
• If the current project is guaranteed to end within six weeks, most non-emergency bugs can wait until the project is done and do not need to interrupt the project.
• The cooldown stage (explained below) builds in time between projects to fix bugs that have come up in past projects, paying down disruptive issues or building better tooling.

Many of the remaining interrupts (e.g., on-call, PTO, etc) should be predictable. With practice, teams should be able to learn what they can usually handle in a normal six-week cycle.

Should we really cancel projects that take more than six weeks? What if we only need two to three more weeks?

For us, the six-week constraint has been more important during the planning and design phase than the actual execution phase. We don’t always cancel projects at the six-week mark, but we do seriously consider it if there are still large, outstanding risks after six weeks.

A failure to finish within six weeks likely means the risks and scope of the project were not properly understood during shaping. It is also likely that risk and scope tradeoffs that should have been made during shaping (with time to get input from a variety of stakeholders) have been left to the engineering team during execution. This will likely result in rushed, suboptimal choices. Rather than double-down on sunk costs, this is an opportunity to step back and re-shape this project with new learnings while the engineering team works on other important work.

Running over by just two weeks might not sound like a lot, but that means you’ve misjudged the complexity of what you thought was a low-risk project by 33%, and that’s a red flag that you’re missing something. Shape Up acknowledges some exceptions for when extending a project might be okay, but once a team is accustomed to planning in six-week cycles, these extensions should be rare. 

In short, well-shaped projects should rarely go over their time allotment. One of the major goals of shaping is to make sure a project will finish in six weeks. If you keep missing the six-week mark, you are not constraining scope aggressively enough.

What if a project will take less than six weeks? Like four weeks?

First, remember that shaping is not about micromanaging time. The shaping process is too early to be planning out things like, “In week one, the engineers will do X; in the first half of week two, they will do Y; and at the end of week two, they will have a prototype of Z.” This sort of planning is unnecessary extra work for the person shaping and ignores the reality that even after shaping is done. There are going to be many small technical risks and surprises that the engineering team will still need the flexibility to deal with as they implement.

If you’re sure you’re not making the mistake of handing out tasks instead of projects, then this four-week project sounds like a “small batch” project that you could pair with another small project, like fixing bugs or something off the engineer’s cooldown list.

In the end, nothing is stopping you from having a shorter four-week cycle for one project followed by cooldown time. But if you start doing this, make sure not to lose the mindset of fixed time, variable scope. 

Shouldn’t we focus more on building high-quality products than meeting deadlines?

The six-week cycle is a constraint on planning, not a deadline for execution. It’s a mental model that decouples the “decide what high-quality product to build” step from the “build said high-quality product” step. The former can take more than six weeks but is focused on de-risking the idea. This way, once you start building, you should be confident that you’re building something of high value and the piece you’ve shaped will take no more than six weeks to build.

During the shaping process, the time (six weeks) and quality of the solution (high) are non-negotiable; shaping is the process of hammering the scope to fit these constraints.

What if I can’t plan ahead well because my product area is new and/or experimental and it’s unclear what the end state should be without building something?

This is exactly the sort of problem shaping is designed to help with. Shaping isn’t asking you to plan what your product will be when it’s finished, it’s asking you to plan for where your product will be in six weeks. 

So shaping becomes even more important for new or experimental products, letting you tackle such questions as:

• What is some high-ROI information I can get in six weeks that I can’t get now?
• What can I build that will be complete (i.e., no expected long tail of bugs and technical debt) within six weeks in case my plans change due to new information?

How do you balance long-term thinking vs six-week cycles?

If you apply shaping to the extreme, you will bias toward extreme incrementality. While erring in that direction is better than having no process at all, you will likely miss out on leveraged value by being myopic.

The solution is simple: Don’t apply shaping to the extreme. Shaping is for tactical execution and planning, not vision and strategy. You need a vision before you can shape away pieces of it to de-risk. This ensures that the six-week pieces add up to something meaningful. 

Shaping also clarifies that a grand vision is not set in stone. Every six weeks, you revisit and adjust your vision based on what you just learned from the thing you shipped (or attempted to ship). Short-term and long-term go hand-in-hand there. You also can stress-test your vision by attempting to shape pieces of it into meaningful six-week pieces; if you can’t do that, something may be off. 

Where product analytics comes in

There are two key aspects of shaping: setting an appetite for investment in a product bet and scope-hammering the solution to fit within that appetite. 

The hard part of setting an appetite is that you may not know the scope or impact of the outcome up front, which makes it feel tricky to decide whether you should spend two weeks on this or two months.

The hard part here of scope-hammering is cutting enough scope that you can get it done within the appetite while not cutting so much that it renders the feature useless/doesn’t teach you anything.

Product analytics is critical here for three reasons:

1. You need a deep understanding of your users in aggregate to make good decisions about which product flows to prioritize as critical vs. leave out as “nice to have” 

It’s expensive and error-prone to do this purely with qualitative user research. Product analytics gives you the ability to more rapidly test hypotheses and explore user behavior to understand what matters.

2. You can use data to assess both the scope and severity of the problem 

How many users are affected? How badly are they affected? How painful are the workarounds they have to take in absence of the feature? These are all questions you can ask as part of a qualitative user research process, but that process can be non-scalable and biased. Product analytics makes it a lot easier to study user behavior in aggregate to better understand scope or severity of the problem and set your appetite accordingly.

3. Finally, every product bet is a learning opportunity

Analytics helps you see which parts worked and which didn’t, so that you can make your next bet (either double-down or pivot) accordingly. This understanding aggregates over time, letting you improve the precision and effectiveness of your product bets.

Shaping your way to a better product

In the end, shaping is all about efficiency. It isn’t, and shouldn’t, feel like extra work. It simply front-loads the tradeoff between scope and cost (as much as possible) to the planning process. 

Without an explicit shaping process, the inevitable research, discussions, and decisions instead happen at unexpected times throughout the project as unanswered questions or potential scope creep are encountered. Because these discussions are unplanned, it becomes harder to get the focus of all stakeholders in the decision, and then quick, technology-focused decisions get made over well-researched, customer-focused ones.

Shaping front-loads these discussions before any time commitments are made. When done right, stakeholders can focus on all the tricky scoping questions posed by a project well before the time-crunch of delivery.

A project that spends a lot of time in shaping may look like it is not making progress, but on our last few projects, spending a few weeks shaping seemingly “hard” problems helped constrain their scope and minimize risk. This has often led to much simpler and faster development cycles once we started implementation work.

When shaping works, the engineering work of implementing features should look simple and boring, allowing the team to focus on building something high-quality. For more on getting your team started with shaping, or at least introduced to the concepts around it, the book (Shape Up) has some recommendations here.

---

Gain insights into how best to convert, engage, and retain your users with Mixpanel’s powerful product analytics. Try it free.