Never get into a bad situation with your customer (no missed estimates!)

Make sure good intentions don’t turn into broken promises and a bad impression: My 9-step plan to NEVER miss a target.

Photo by Loic Leray on Unsplash

So you’re sure you never told the customer it would take two weeks?

Absolutely, I never promised we could do it in two weeks. Totally sure of that!

Ok, then why are they saying we’re late, and demanding we make up for lost time?

No idea. When we talked about this, I was very clear. I told them the earliest we could get it done was 2 weeks. But it might be four. Two if we’re lucky and four at the outside. Probably three.

Have you ever been on either side of this conversation?

Anything we say to our customer, even the most innocent and well-intentioned exchanges, can quickly turn into broken promises.

There’s only one situation where I’m comfortable talking about time and cost: When I’m absolutely certain my team can commit to a specific date. Which is rare, because we usually don’t have that kind of confidence.

But that introduces a conflict I know you’ve run into: Customers want to know “how much” and “how long” before pulling the trigger on any project. It’s reasonable. Someone has to pay for all this work. Or possibly a specific date is important, like a launch that’s tied to a holiday. So how do you manage situations where your customers wants hard answers, but you don’t have them?

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

Handling ambiguity

As the delivery team, we are constantly pressured to give concrete, absolute answers about time and total cost. Time equals money, by virtue of keeping a team employed. A team of eight people, plus whatever resources they need to work, needs to be paid for — and most customers need to know how long they’ll be on the hook.

And it’s a constant demand. Maybe we’re hoping to win a new project, and our future customer earnestly needs to know what they’ll have to pay. Or we could be planning our next iteration or sprint, talking about specific features, and the product owner wants to know, “How much is that feature going to cost me? How long will it take to build?”

It’s unreasonable to expect your customer to write a blank check, or have no confidence whatsoever about when their project gets finished. They need some level of certainty. Certainty about costs not growing beyond their means. Certainty the product will be usable when they need it.

At the same time, you can’t pull answers out of thin air. Programming is research and development. That means we don’t have all the answers, we have to research theories in order to create answers. Those unknowns become dependencies that affect the whole project. After all, if the solution was already known, we could probably just buy it off the shelf for $99.95.

But one of the worst things you can do is put forward an answer that you don’t have confidence in. It’s hard, I get it. Your customer is pressing for answers and doesn’t want to move forward without them. And that’s exactly why you have to be very thoughtful and intentional when talking about cost, schedules, and delivery timeframes. Giving the wrong answer is just going to lead to mistrust.

Always recognize that whenever you give an answer it’s going to be passed from one person to another, likely simplified, generalized. “Two weeks, maybe four at the outside” quickly turns into, “they said it’ll take two weeks, maybe more but he was pretty confident about two weeks.” And that, in turn becomes, “you promised two weeks.”

The wrong answer is way worse than saying, “I don’t know.” But you can’t stop there, because a blunt “I don’t know” isn’t going to create confidence.

When dealing with ambiguity (like how long something might take) we need to have a method in place for dealing with unknowns. We need a system — and that system will build trust. It builds tolerance for the unknowns.

Creating certainty out of ambiguity

Your customer wants answers. They need enough certainty so that they can make a “go, no-go” decision.

How do we create enough certainty for our customer when we also have to live with ambiguity in the project? How do we find a mutually acceptable path forward? And what’s my “formula for avoiding misunderstandings?” Let’s dive in.

I approach estimation knowing that nobody is going to have all the answers they want. I won’t have enough information to accurately set a target delivery date. The team likely won’t have enough clarity on features, specific business requirements, and certain metrics until we get further into a project. Our UX designer isn’t going to figure out what the product looks and feels like until we’re somewhat down the path. I’d love to know all of these things right at the start of a project — but these answers just don’t exist yet.

These are all dependencies. Until we resolve the dependencies, we can’t formulate an answer with any reasonable degree of certainty. But, you also don’t want to seem like you’re just making excuses for not having answers.

Explaining these dependencies to your customer is a good place to start, and doing it with the intent of mutually finding answers is the right way to do it. You want to define the problem — the ambiguity — as a shared problem and create a collaborative path forward toward a solution. In other words, enlist your customer in helping to create certainty. Make it an “our” problem, not a “your” problem. You want to know the delivery date just as much as they do!

Your customer would love to hear exactly how long the project will take and how much it will cost. But you don’t have the entirety of that answer. It will take time to find those answers, and time isn’t unlimited. That’s why establishing a clear path and steady progress markers, a way of keeping your customer informed at every step, is so important.

Finding a mutually acceptable path forward

The first step is building a really clear shared comprehension of the business functions you’ll be developing. It’s a tricky stage of the design process, simply because underestimating complexity almost always happens. The inner workings of a system are hidden, and our brains are very good at concealing all that complexity. Just about every conversation I’ve had with customers glosses over complexity — often to a ridiculous degree.

Right now I’m working with a customer who uses a spreadsheet to manage medical records. It’s cumbersome, error prone, and takes tremendous manual effort to do correctly — but it’s just a spreadsheet. Day-to-day work amounts to opening the file and editing it. When it comes to building a product around this, the complexity of doing so is completely foreign to my customer: Understanding their data, building a data model, creating a bullet-proof user experience, designing a data store, validating inputs in the user interface, defining APIs and choosing technology, building backend validation, testing everything, not to mention things like authentication and data encryption around PII (personally identifiable information)… and so much more.

It’s not enough to just throw a massive list of work at them, saying, “Look, this is what we have to do.” We need to have a shared understanding of the work and an appreciation for it’s value. Otherwise, it’s just meaningless effort in their eyes.

Laying out your dependencies and explaining how it impacts timing and cost decisions can be challenging. I don’t recommend just diving into this conversation without forethought. Take time to prepare. Think about who your audience is. The CEO at your customer isn’t going to want to dive down and talk about whether JSON or Protobuf or Avro is a better protocol. She most likely will want to talk about whether customer data should be encrypted in flight, and whether the businesses risk profile demands securing cloud-oriented attack vectors. You’ll want to keep the conversation at the right level.

You don’t need to have all the answers, either — or even all the requirements! In fact, the whole point of this conversation is to introduce challenging questions, making it clear that you cannot possibly have all the answers yet, but that you have a system, a methodology, for finding those answers.

So step number one is building that shared understanding — for that, I love using event storming. It keeps the conversation at the right level. The focus at this stage is on figuring out what the system needs to do, and event storming focuses everyone on what actually matters to the business. It exposes important problems — for instance, dependencies between different business functions, and even the importance of having a good authentication system. This is why event storming is part of my Delivery Playbook, and one of the first tools I use when engaging with a customer. It’s a powerful discovery tool that yields an abundance of information early.

The really neat thing about event storming is that business problems and process ambiguity is exposed. Hiccups, inefficiencies, and missing information in how the business functions (and how it might improve) pop out. What I love about it is your customer sees the unknowns right off the bat. Those problems come out as tough questions about how the future business should operate. Those questions have to be answered by your customer and that means you are pulling them into the design process early. It clearly demonstrates how their application isn’t quite as simple as they may have imagined while also demonstrating an effective design approach!

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!