At the point someone decides we need to add a new feature to the platform / product / site they have three things in their minds: a clear vision of the feature; a sense of when it will be needed and a sense of the value it will add – what we call the What/When/Why information. In many technology driven environments this is the last time these three pieces of information will be in the same place at the same time. As a result of this, we only build the hard things, and everything costs more than it should. If we want to do more with less then this is a good place to apply some thought.


Let’s look at how the process works in most organisations and how that creates issues. Let’s imagine the CEO has had a great idea. In a week’s time she has a meeting with a potential customer who has a parent company based in Paris. She’d like to show the customer that her platform has a French language interface as well as the English one she’ll be demoing. The hope being the customer will mention her product to their French owners. Susan knows three things: The French interface looks just like the English one but has French text; I need it for next week; it might be worth nothing but, equally, it might lead to a very big sale.


The CEO talks to her CTO and explains her idea. The CTO has been thinking about language support for a while and sees an opportunity to take the idea forward. He talks to the head of product, who to be honest was actually the person that thought of language support first but now, apparently, it’s all the CTO’s idea. The head of product talks it through with the head of development. Turns out they already figured out how all this could work a few months ago and pitched the idea to the CTO but it didn’t seem to go any further. They dust off their ‘Lexicon Epic’ documentation and head down to where they keep the developers. At this point it’s worth noting that virtually none of the information that was in the CEO’s head has survived.


The head of product and the head of development go and see the lead developer on the UI team. The lead developer is super busy so suggests, as this is a self-contained piece of work, that they can discuss it with a more junior and more recently hired developer. The developer listens to their explanation, looks at the ‘Lexicon Epic’ documentation and tells them it’s three months’ work. Everyone goes back upstairs and tells the CEO it’s a three-monther. It’s not mission critical so the CEO moves on.


The above story really happened, and I was the junior developer. It was weeks later, while at a company social event, that I heard all three pieces of information the CEO had in her mind. She also asked me this:


“What would you have said if I told you I needed it in 1 week?”


My answer was, “I’d say I can do a proof of concept showing you four screens in French accessible on a different URL to the main platform”. Which was exactly what she needed.


The people between the idea and the person that delivers the idea add value, remove risk and provide continuity. But if we rely on a military chain of command type information flow we too often end up with disconnects like the one above. Here’s how we avoid these at VDP.


For any platform we own, manage or develop we have a short meeting once a month (usually coinciding with a show and tell of the last 2 sprints) with the most senior brain we can lay our hands on. And everyone comes -developers, testers, designers you name it. The purpose being, not to talk about our progress but to talk about the evolving vision of the product. What have we heard from potential customers? What are competitors doing? What are we most excited about? What seems less important than it did. All this information and, crucially, the What/When/Why information that underpins requirement ideas is then shared directly with those best placed to find ways of delivering it. We have a rule that no requirements can come in directly from this route. We still circle back and pull together specs and opportunity costs, but when these requirements do at last make it into the backlog the What, When and Why are still intact.


If this sounds a bit like a start-up that’s because start-ups are good at this. Internal communication is easy when you can all fit in the same taxi. It takes a deliberate effort to ensure this quality of information flow isn’t buried by growth.