Sometimes The Truth Hurts
But it’s still better than the alternative
Hopefully we can agree that lying is a bad idea¹, if for no other reason than you’ll eventually be found out. If you’re responsible for delivering a product and actively lie about what you can deliver, or when it can be delivered, then you are needlessly digging yourself into a hole from which there will ultimately be no escape. So don’t do it.
However, there’s also the murkier business of untruth by omission. This is easy to fall into; you don’t want to disappoint people by telling them you can’t deliver something, or that their idea is rubbish. This is understandable, and probably morally better than actively lying, but it will be just as detrimental in the long run, and should also be avoided. So below are what I’ve found to be the most common untruths by omission, and what you can do to avoid them. I call these:
- Sir, yes sir
- Moon on a stick
- That’s great guys
Sir, yes sir!!
What is it? Your boss wants more delivered, quicker. Of course they do, they’re the boss. Or, even worse, they want to take a detour from a feature that’s 95% complete, and prioritise some other random thing in the next sprint.
What you definitely shouldn’t do: Sadly we’re not just paid to do what we’re told, so don’t say “sir, yes sir” and then jump to it. You know that the team is at full capacity, and that cramming in more work without compromise is going to turn the roadmap into a traffic jam. Don’t just say “no” either though, that’s a terrible idea². Confused? Feeling a bit like Matt Damon in Ocean’s Eleven? Don’t worry, there is an answer.
What you should do: provide context. If you’re currently planning to deliver Feature A and Feature B, and the Boss wants Feature C instead, then something has to give, and you should be clear that this trade off will need to be made. Ask them what they would like to deprioritise to accommodate the new thing. Be clear that these are not forever choices, just because we’re planning to deliver A and B in March, it doesn’t mean we can’t do C in April.
Initially it may be daunting to have this sort of conversation with senior people, but the important thing is to frame it as discussion about timing and priorities, not a binary choice about delivering one thing and not another.
Moon on a stick
What is it? You’ve got a great group of beta users, they’re always happy to try new features and provide you with their feedback. They also like to give you their own ideas for the product, some are good, some are indifferent, some are terrible, or impractical, or too niche and low priority to ever be delivered. For some reason, it’s the ideas in the latter three categories that your beta group will be obsessed with, which is a problem.
What you definitely shouldn’t do: don’t make them feel that ideas you know will never be implemented have a chance of being delivered. I watched this happen in my first job as a project manager and it’s not good. We had a great group of beta users who were full of brilliant ideas for developing the product , but we were subject to a massive budget cut that meant we would only ever be able to deliver a fraction of the original scope. The Product Owner was happy to face this reality with the project team, but did not want to discuss it with the beta users, and wanted to keep having brainstorming sessions with them to generate ideas we would now never be able to implement. We should have been refocusing the beta group on helping us deliver the best product possible in the new circumstances, instead of leading them on a wild goose chase, and the delay in telling them the truth disheartened them and made them cynical about the whole process.³
What you should do: be kind, but be honest. If a suggestion won’t be implemented then tell the person who suggested it why not⁴, providing wider context can help in this situation as well, and if they’ve got other ideas that you are keen on, then focus the conversation on those instead. Agreeing to disagree is fine as well, if you’re the Product Owner/Scrum Master/Project Manager/whatever, then you have a lot more responsibility for the final product than even the most engaged beta user, and there’s no harm in pointing this out if you can do it with a dash of humility and are prepared to admit that yes, you might be wrong.
That’s great guys
What is it? The development team delivers something you’re not totally happy with as Product Owner. It’s ok, and can still be released, but it’s not quite right.
What you definitely shouldn’t do: ignore it. It might well be good enough to release, but the development team has not delivered what you wanted. It’ll be tempting to nod it through and congratulate them on a job well done, especially if you are actually happy with the other ten things that got delivered in the sprint, but if the team hasn’t delivered what you expected you need to understand why.
What you should do: just ask. Why didn’t you get what you were expecting? The fault may be with you, maybe there was something you didn’t explain properly at planning, a nuance or ambiguity that wasn’t discussed, maybe there were gaps in the explanation that you didn’t realise. Maybe the development team had to make compromises in the implementation, if so, why wasn’t it discussed at the time? It could be something else all together, but the important thing is to find out. If there is a problem in your planning process that has created a small problem, it could easily create a big one.
Obvious Conclusions
- Don’t be afraid of uncomfortable conversations…
- …but try and frame them as positively as possible
- Be honest…
- ….but try and do it with a bit of empathy and humility
¹ Clearly that’s not a very nuanced take, but this is a blog about successfully delivering software, not moral philosophy.
² I speak from personal experience
³ Not unwarranted in the circumstances
⁴ At the risk of stating the obvious, this doesn’t apply to anonymous suggestions submitted via a web form or whatever, only to people that have engaged with product or project over an extended period.
