Shape Up Forum

Any stories of Shape Up adoption failures?

We’re about to adopt Shape Up on our team. We’re very excited. I’m also seeing some distinct risks.

I’m curious if there are any stories from folks who have tried and failed to implement Shape Up or failed to get great results with it? What went wrong? Any post mortem lessons for us?



I’m working on something (sadly a blog post). I’d be happy to talk at your convenience :blush:


We are about to embark on Shapeup … no pressure :slight_smile: hopefully your blog post is out soon enough for us to read it - and watch out for any pitfalls or areas of concerns.

While we wait to hear from folks on the problems they’ve encountered, could you share the distinct risks you’re seeing as you look at adopting Shape Up?

Sure! These are not insurmountable risks, and a few folks in this forum have pointed out mitigations to these. I’m just curious if anything became a reason to revert to a past process or move on to another one.

  • Requires high trust in the Builders (designers & engineers) at every level of the organization, including stakeholders
  • This is a new mental model for many designers & engineers. How many get stuck in past ways of thinking?
  • If Shapers are totally hands-off, is execution impacted?
  • Were the larger cycles too much of a risk for the business?

Our team is still using Shape Up (2nd full cycle underway), but a few kinks we noticed in our previous cycle (that we are working to address in this one) include:

  • Lack of team input on the appetite. Some team members felt the appetite was unrealistic and did not feel empowered to push back. We’re now doing project orientations before the start of a cycle to mitigate this.
  • Unclear review process for product/design. We have defined a process for the next cycle.
  • Too much/little detail in the pitch. This is something we feel will naturally improve over time.
  • Cool-downs being used to finish projects. This is a problem with the team or the appetite, and something we also feel will naturally get better as we understand our team’s capabilities.
  • Lack of easily-reviewable information about project decisions. Aka there is no final spec and it can be cumbersome to wade through a project to understand what the final deliverable looks like because it can vary from the pitch. We haven’t figured out a good solution for this yet!

Not having high trust in people (either because you can’t give it or because someone doesn’t deserve it) is a more fundamental problem that can’t really be solved with process so I don’t think it’s a reason to avoid or discount shape up. If anything, Shape Up would give individuals a chance to grow in those areas that require giving/getting high trust.

I’ve distinctly seen two buckets when initially implementing, those that try to adapt Shape Up into past ways of thinking and those that adopt their own approach to fit with Shape Up. I honestly think the people who actually read Shape Up cover to cover are the ones who can shed the past more easily. It becomes easier once you get a few cycles with successful hill charts, scopes, etc. and can use them as examples for others.

If previous processes requires the people now called “Shapers” to be fully engaged in execution, and now they’re completely hands off, yes it will be impacted if others depended on them. We haven’t found any way around product managers being completely hands off during the cycle. It doesn’t really seem practical and it also doesn’t really seem to be a fundamental principle of Shape Up. I might be biased though because I don’t want to be completely hands off :smiley: but I’m also not being pushy or just checking status, actually solving problems with the team is where I want to get involved. Shapers also have to be involved when it comes to making trade offs unless they’re crystal clear about must haves and nice to haves which is never the case.

We don’t find larger cycles being too much risk, what we find more often is that we need to weave small batch projects between larger batch so that we can focus on either customer-specific requirements or small refinements that we consider to be blocking larger progress. I think this will smooth out over time and we’ll do more big batch cycles than small with some mind set changes - for example, if something is working but engineering thinks it needs to be refactored, then make sure that’s being taken into account when de-risking a project that touches that part of the code base, so they can leave it better than they found it, rather than dedicating a project to black-box changes.


We have just ended our 3rd cycle, sharing some observations, learnings, and tips.

  • Not getting the level of abstraction right: Many of our pitches go too close to the implementation detail or are just theories. If you start to see implementation details in your solution, take a step back and read more on this. I’d recommend this video, where Ryan discussed where this idea came from. It is important to get the abstraction right.

  • Not enough research or pushing the research downstream: Sometimes, the shapers don’t put enough time to research the problem or the solution. This results in the research work being pushed downstream and delaying the projects. Thumb-rule: (Most) Research is for Shapers.

  • Rushing the shaping: We found that shapers were rushing to write pitches too late. This will almost always result in bad pitches, especially if they’re too hands-on during the cycle. Shapers shape during the cycle, while builders build.

  • Grab bags: Often, shapers are inclined to group multiple small-batch projects into an umbrella term of “improvement” or other such vague terms. Keep an eye out for these and split them into ad-hoc tasks or small-batch projects (depending on nature and size). A weak and vague problem statement is a good indicator of such a project. Bullet lists are another.

  • Carrying in the notion of working in silos: If your team worked in silos, it has to change. Building demands collaboration. Assist them in leaving the old way of working behind. It will only help them grow in their career, regardless of which process they use.

  • Just reading the book: Shape Up is different in many ways and will require a mindset change in the whole team. Just reading the book is not enough. Understanding the principles behind is equally, if not more, important. If you’re the one evangelizing the process, you’ll have an additional responsibility to educate the team on this topic :smiley: A responsibility I personally enjoyed.

I hope this helps you equip better for your journey. :rocket: