It’s easy and necessary to make assumptions. If we didn’t make assumptions then we would never make any progress in our work; we would have to stop and check everything. Making assumptions is not entirely bad.

But sometimes it’s important to check our assumptions, and explore other possibilities for solving a problem. A common example came up recently in a conversation with a developer. They had been asked by a product manager to come with an estimate for a piece of work, and an initial finger-in-the-air response was that it would be about six weeks. The product manager wasn’t happy with this and started to push for what the developer saw as compromises. The developer hadn’t done any detailed work, but was braced for a head-on collision in which she said “it is what it is” and the product manager would simply not accept that.

This is a pretty common situation, but I’ve found it is often reconcilable. I spoke to the developer about us all sitting down together and exploring options in more detail—not just options for what might or might not be included, but how we might structure and deliver the work.

In the past I’ve found that a stakeholder can be very happy with an earlier delivery of less functionality, even if that means the development team spends more time overall developing the full functionality. So, perhaps they would prefer four weeks plus four weeks rather than one delivery in six weeks. In some cases I’ve found that the stakeholder is not even interested in (what was assumed to be) full functionality, so they get the necessary functionality delivered in (what is to them) a reasonable timescale and the development team can still build it in a way that (to them) is of respectable quality.

Too often there are assumptions on each side that aren’t even recognised as such. Sitting down, talking, and approaching the problem from different angles often produces unexpected insights and opportunities.

Photo by Joel Kramer