What is your experience of bringing Shape Up to client work?

Hi everyone,

I’m really interested in learning from individuals who brought Shape Up practices to their client work. Specifically freelancers/solo consultants.

The past few years of client work usually start out the same for me:

  • Do a decent job of exploratory work in the beginning of the relationship.
  • Build some product for the client.
  • Iterate some ideas because some unforeseen supply-side constraint.
  • Eventually start down the path of the dark side with endless email/ticket system of work without wel defined scopes or trade offs.

I am quite interested in how you have:

  • Gotten clients to agree to setting a fixed time and variable scope.
  • Set expectations with clients to consistently participate in shaping/discovery work.
  • Designed systems to hold yourself accountable to avoiding scope creep and facilitate work cycle after cycle.

What else from the Shape Up book did you find difficult to implement in client work? How did you modify the strategy to meet your needs?

Thanks @rjs for putting this forum together


This has been on my mind as well, @marcano. I sometimes take on freelance work on the side and would really prefer to approach all software design and development the Shape Up way.

I haven’t had a side hustle since starting this process, but I have roughed out a plan for what I’ll do when a finally break down and pick up some extra work:

  • Instead of billing hourly, I will bill weekly. I feel that the framework in which a client is paying be should help somewhat in establishing the philosophy.
  • During Shaping, if after any week they don’t feel like we’ve made reasonable progress, we can review expectations and see what’s off.
  • If Shaping has already been done, or if the project is fairly well defined already, my first step would be scoping with an aim of deploying something each week.
  • Again, each week if they feel I’ve not made reasonable progress, we can review expectations.
  • Because I’m always working on shipping tightly defined scopes, they have the freedom to fire me at any point without fear of losing the work. If they don’t like the process, there is product in place for them to build on with someone else.

If and when I actually try this, I will report back.

1 Like

Excellent question. I have been bringing Shape Up to my client work and I use a combination of Wardley Maps and Shape Up to address the demand and supply side ( I suppose you are familiar with Ryan’s demandthinking.com).

In terms of how to get clients to agree on setting fixed time and variable scope, I use Agile as a straw man and highlight rituals that are pervasive among startups and orgs claiming to follow True Agile. Using a cultural ritual metaphor conveys the point very convincingly, especially in a country like India. *rituals

I’m thinking this through on a possible new client, so I’d like to hear other people’s experience too.

Two things that are coming to mind for me: The notion of “bets” and the notion of having some “skin in the client’s game”.

I can’t remember if it’s on Jonathan Stark’s or Blair Enns’ podcast that I heard this bit, but when moving away from hourly billing, fixed scope development work, it’s all about assuming risk. Say you have three options in a proposal:

  • Option 1: highest price, lowest risk to the client, highest risk to you because you guarantee the result, anchored high to encourage going for Option 2
  • Option 2: a different price/package, where you assume some of the client’s risk, and guarantee an outcome
  • Option 3: lowest price but the client assumes all the risk (fixed scope but variable price and variable timeline, e.g. hourly billing, daily rate, etc)

To my mind, to get to an agreement of variable scope, fixed time, we have to assume some of the client’s risk as an external entity. They can’t own all the downside. Contractors are known to not have skin in the game.

And then there’s the notion of making bets. Certainly, having three options forces the client to choose an option where they trust me more (the option with the highest cost, highest risk to me), so they’re already making a “bet” there.

But then there’s having them make a bet on their business by choosing to have me implement the highest option. In the process of that option, we’ll have to speak about the needle they want moved, and what they’re willing to part with to make it happen.

So that’s my take. Bets and risks are core to Shape Up, but with an arms-length client relationship, it’s about sharing in their risk, and bringing them to place bets together with me.

Reactions? What am I missing?

I like this idea. I also feel that hourly billing is kind weird. Hour != hour. Sometimes you’re productive and sometimes you’re not. The weekly billing seems fairer to me. On the other hand, I would expect some resistance from client. Did you try to ask them? Did they agree with it?

I have not tried it yet, but my friend and colleague, David has been doing it for a while with a fair amount of success. You could ask him.


Suuuuper weird. When you think about it, it doesn’t make much sense for us to bill for our time.

Hourly (or any time-based) billing makes it easy to get started before you really know what you’re trying to achieve (I think that’s part of the reason it’s popular among devs) or when you don’t know how long it’ll take you (also a favorite among devs), but Shape Up should actually help you avoid both those pitfalls.

The client doesn’t care about how many hours we put into it, they care about the result. The time it takes is part of your costs, so you just need to make sure you’re pricing the project high enough above that to make it worth your while. But that should just be a minimum boundary for the price of the project, not the way you determine how to price it.

All that to say, while you’re rethinking the way you run your projects, you might also take some time to question the way you bill for (or really, price) them too.