I missed a critical step in effective product development

Recently I wrote an article called “In the digital space you are better off fast than right”, which suggested two key elements to creating digital products were critical to success, namely: 1) Having agile processes/technology and 2) Making decisions quickly.

When I arrived at the office after writing it I could see there was something up. Our Chief Technology Officer approached me for a chat. Now I have to say of all the people in the company, he has been one of the most encouraging of my writing. He himself produces some great stuff on his blog and has offered to help me whenever I need it.

He then gave the perfect example of upward management. He started by being complimentary of the fact I had been sticking with my writing and that the flow was great. Then rather than tell me he disagreed with what I wrote, he started asking some really good questions and he asked them like he was truely interested (which he was). But he was obviously also using them to try and guide my thinking and get me to question further what I had written. The two key questions that did that for me were:

1) There are lots of other theories out there in terms of how to best successfully approach product development. Did I think being agile and making quick decisions was the right approach in all product development situations?

2) What happens to the team if the quick decisions we make are wrong. How does it impact their moral, how will they react?

These are two really good questions and made me realise I’d stopped a little short in my first article. 

I still believe being agile and making quick decisions are critical. Maybe it’s routed in my personal experience, where too many times I have seen good projects just disappear over time or produce a poor end product, because they just lagged. To see a team invest their time in something for 6 months, only to realise it doesn’t work when it’s taken to market is soul destroying.

So there is a third element that does need to be stated should you choose to go the agile/quick route:

You must have an affective feedback loop in place, that tests your hypothesis (which you need to have up front) and allows for validated learning to happen, reducing technical debt. Not learning in the sense of, “It didn’t work and we learnt this”. But rather learning in the sense of “We believed [A] to be true, so we built our product to prove [A], but our product showed us that [A] wasn’t true, but we learnt [B]. Now we will start the build, measure, learn process again, proving (or disproving) [B]”. This is a process evangelised in the Lean Startup by Eric Ries. 

To be clear, I’m also not saying “The Lean Startup” is always the way forward. What I’m saying is that if we choose to be agile and make decisions quickly, then we have to be clear what it is we are looking to test and be willing to change our strategy if our hypothesis is disproven.

So I do agree with my CTO that there are different ways to approach the process of creating digital products, but as a business owner I want to know that if we invest our time in something, we do not spend too long on it, without proving that we are reducing the odds of failure when it gets to market. We need to test our assumptions and hypothesis’s early and learn as quickly as possible in order to adapt accordingly.

But knowing my CTO, that is exactly what he was trying to get me to think about in the first place. I’m sure if I’m off the mark he’ll be letting me know.