Beware the Answer
In almost all fields, most people are searching for "the answer." The silver bullet, the cracked code. Product development is no different.
“Scientific management" arrived on the scene before 1900. Taylor’s methods lit a match under the modern pursuit of the "right approach" to making things. A pursuit that has exploded over the last 15 years.
Those of us working in software enabled products are drowning in versions of "the answer". Process driven iterations of scientific management are everywhere. We're all agile now, whether we've considered the manifesto or not. MVP is on everyone's lips, even if it almost never lives up to the spirit of the original definition.
Many people also look to a new set of technology frameworks to provide the fastest, easiest path. With the right tools, surely no waste will slow down the construction of new and innovative ideas.
Consider the ratio of talk about innovators and their dilemmas vs. actual developments that are new and uniquely useful. Many recent approaches to "the answer" are those that aim to help decide what to make. Whether you subscribe to service design, jobs to be done, or something else, there are more frameworks than ever to apply.
The makers of these methods refined them to be used in a narrow sense, with care and skepticism. But, once popularized it is all too common to see them applied broadly. The results are often presented as fact and not the best interpretation at the time.
The simple, but not easy fact is that we're all competing against luck, no matter what tools we use.
Product makers should invest in deliberately learning the latest approaches, then practicing them. Combining fresh methods with fresh assumptions may not be a sure thing, but it might bend the odds favorably.
Any of us is going to be lucky until we fail, or fail until we're lucky.
Most people bold enough to try their hand at product development have to assume they're going to be lucky. The prospect of being wrong is what prevents many from even trying. But, once armed with "the answer" many bet they'll be successful.
It's hard to get any product development effort off the ground or its direction changed. Funding, approval, alignment, team buy in, or any number of other things can stand in the way. It's tempting to think that once we take care of those hard things the output should be easy. It rarely is.
Big ideas are easy, execution is hard. Most people think the opposite.
Start with the assumption that you are almost certainly going to fail, and you might need a lot of attempts to get lucky. No approach or tool can eliminate that possibility. It can help guide you much earlier to a way of working that is very easy to talk about but very hard to do.
Those of us doing this work are all human, and human beings rationalize. This makes it very difficult to assess results without telling ourselves the wrong story. Embrace the human limitations of yourself and your team. Plan to counteract them. Set up both your execution and your feedback loops to learn how wrong you are earlier than what you think the right time is. Then reflect on whether you can cut it even shorter every iteration.
Put systems in place to make it hard to rationalize what you assumed before the results came in. That way you can be less wrong sooner, and you've got a lot more at-bats.
There is no answer. Learn, apply, and go fail until you get lucky. If you start lucky, celebrate and get back to work. For most, luck is fleeting.
Have a story about when you thought you had the answer? Or someone you worked with? Tell me about it. cs@craigsturgis.com
(This post includes affiliate links.)
Join My Mailing List
- New Posts in your inbox.
- Interesting things I want to share.
- Not too frequent.