The one in which I talk about how much better it is to understand a problem before trying to solve it.
It is Tuesday afternoon in the office. You hear a story of a customer request and you really think that you could use AI to address that. Should you do it?
The answer depends on what you want to optimise for. The feature or the problem.
What will you optimise for is a very important question at this point in the process. You have a problem, you believe to have a proper solution for that problem, so why not go and do it?
Going ahead with the single solution you thought of will put you on the path of optimising for the feature.
If that feature falls slightly short of solving the problem, the goal becomes then to improve and iterate on the feature instead of using the problem as a guide.
You decided to optimise for the feature.
We must not ignore that, optimising for a feature that is already on your mind, will allow you to move faster. You already have an idea about how it looks like, heck, maybe you even have wanted to do it for a while and used some good time to think it through.
But beware; this puts you in an optimal position for being a victim of confirmation bias.
There are other ways to go about this.
Let’s say you heard of the customer desire but instead of fitting your solution into the request, you decide to dig deeper into what is behind the customer request.
From that list of expectations and desires, a list of outcomes instead of features, you can start to think about ways to solve that. And here’s the subtle difference.
Whenever one of your ideas fails to achieve the desired results, you are not bound to it. You are only bound to the list of outcomes you gathered. And that is what will drive your iterations.
There is a good argument around defaulting to build and see what happens. I am a big fan of experimentation in user space and testing things instead of theorising about them.
With that said, I also believe that you cannot test/verify what you can’t understand yet. And that understanding becomes very hard whenever all that you have are a feature request and the infinite number of assumptions we carry in our heads.
When you have understood the problem.
You might be thinking: “Yeah, but I cannot wait forever until I know everything before I start to build. My competitors will get ahead.”
You’d be right to think that.
You certainly should not spend more time understanding the problem than you would otherwise. In fact, using the example in the beginning, you can do most of your understanding on the spot, with the same customer.
The main points of optimising for the problem are:
These three steps build the feedback loop you need in order to discover what to build and what to experiment with.
Whenever you present a hypothesis paired with a solution and you get an answer that is positive, you know that there is something there.
Whenever the user is uncertain, maybe she doesn’t get it yet, or is too stuck on the feature she wants, you may decide to experiment. That is, given your conviction on it is right.
The key here is that you and the users agree on the hypothesis and outcomes. Because in most cases you only think that you agree :D
After that, iterate. Iterate on the problem.