Building by problem-solving

I used to focus on learning the ins-and-outs of design and code. The fundamentals as well as the latest shiny things. Lately I have been learning more about product design, management, entrepreneurship, and leadership. More of the “‘why” over the “what” and “when”.

The longer I have exposed myself to the process of building a product, the more I learn. As it should be.

What I’ve often learned is how ignorant I am to most things. That we need to approach each new opportunity with a beginner’s mind and to ask a lot of questions.

We need to focus hard on determining what the actual problems are that need solving. To not even entertain a discussion around a solution until we nail that down.

We are taught to follow the obvious path not to challenge what we are asked to do. If we don’t ask the right questions, most of the time we will end solving the wrong problem.

From there we need to make some hypothesis on what might fix the problem, and then test our assumptions. We need to build into our process the time to learn.

Are we on the right path? Did this result in the outcome we hoped for? Do we know what outcome we hope for?

Without this approach, you are building a feature factory. Pumping out new code and types of design with no means, or care, to measure results. It adds up and hurts you in the long run.

Being able to say “yes, we do that” works great on phone calls. You’ll grow quickly. But what you are essentially doing is passing the buck to your future self.

When you’re focused on solving problems you end up with a better product. One that is less bloated. Making it easier to maintain as well as making your customers happy.

Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions.

I still have a lot to learn. The work is not simple. The answers are not easy. But, this approach to the work guides everything else.