Welcome to my website!

The center stage effect

I have found that when having to ask a client/product owner for more time to complete a part of the project it is usually good to present them with:

Three options

  • One Is what we consider included in original estimates, often a stripped down version with a lot of manual work required on their side.
  • Two has more automation and selected cool features, but will mean a slight increase in estimated hours (adding cost). Agreed release plan will be kept.
  • Three is the best case scenario with all nice to haves. Will mean a larger increase in hours and will push release dates.

The different options you base on that more detailed planning and estimations has been done, this will create confidence that you have done the required steps to be able to conclude with what you are presenting.

Two is the safe choice

Psychologically, this will push them towards option two, since one is not acceptable, but three will be too expensive and could mean postponing a delivery.

By presenting the options like this we not only give the client a better understanding of what they will get as part of the delivery, but they have also actively agreed to add hours (and cost) to the project to ensure a good product. Clients usually also like to feel included in decisions and will in many cases be more happy with this approach, even though it means added cost, compared to not being informed and getting a product with less features then expected or at a grater cost in the end.

As a side note, we don’t let the client know this, but option two is usually what we intended to deliver to begin with, but since we have to get the customer to pay for the extra hours we are missing (due to underestimating the task), we can opt to present it this way.


If they choose option one, it makes them aware that they will get a simpler, more stripped-down version. If they choose option three, then its still considered a win, because then we have aquired even more hours into the project.

Keep in mind that option one has to represent a minimum of what you are happy to deliver. Stripping this option too much might not result in a viable product.


One example, lets say we are setting up a webshop/PIM with multiple available providers in regards of product data:

  • Option one, supporting market model with mapping. Manual enrichment of data into the model. Integration between PIM and webshop.
  • Option two, supporting market model with mapping, in addition we integrate with the two biggest providers to get automated import of data. Integration between PIM and multiple channels available. Will keep agreed release dates.
  • Option three, supporting market model with mapping, in addition we integrate with the 4 biggest providers to get automated import of data. Integration between PIM and multiple channels available. Will mean postponing release date.

Adapt to project and determine pressure points

Off course the options will have to be adapted to fit the project in mind and the initial plan and scope. Using this method is usally simpler if the overall plan isnt very detailed since it gives more room for adding or removing features in the different options.

Using the release date as leverage will only work in projects where this is important for the client. The main point is to use key pressure points as leverage to be able to nudge the client in the direction you want.

Extra effort required

Using this approach will require you to have good control of the estimations and tasks required on each of the options, also option three which has the least chance to be selected. This extra effort isnt wasted though, since you can add these tasks to the wishlist and reintroduce them into the project once first phase is delivered.

Some supporting theory on the subject can be read here:

Leave a Reply

Your email address will not be published. Required fields are marked *.

You may use these <abbr title="HyperText Markup Language">HTML</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>