“Technology First” vs. “Problem First” Product Development
How to build meaningful experiences starting with innovative technology
A friend was visiting us last weekend, and while I was putting together thoughts on a new product concept that leans into the possibilities unlocked by Generative AI, he asked me how the approach I was taking compared to the standard product advice that usually tells you to “start with a problem, then build a solution” and “above all else, focus on the user.”
To him, what I was doing was starting with the technology - something that seems to go directly against the standard product advice, and usually ends with a product in search of a problem.
While I generally agree with this advice, I don’t think it’s the only way to build amazing products. This is particularly true for novel products and features that are made possible by breakthroughs in technology; a situation which I've grown increasingly accustomed to over the last 6+ years of my life. Another way to think about building these types of user experiences is “opportunity first” vs. “problem first” product development.
Some features I’ve launched in this category include:
Continued Conversation [announced at I/O 2018] - allowed users to seamlessly ask a follow-up question to their Google Assistant without having to say “Hey Google” again
Simple Stop [announced at Google I/O 2019] - allowed users to simply say “stop” to their Google Assistant speakers when an alarm or timer was going off
Quick phrases [announced at Google I/O 2022] - allowed users to issue a set of phrases, such as asking about the time or weather, or turning on/off their lights, without needing to first say “Hey Google”
In each of these cases, I was working with a team that was innovating on core speech technology, and it was my job to figure out how those advancements could enable meaningful new user experiences. Also, in case it wasn’t obvious, I spent a lot of my time as a Product Manager leading the Google Assistant Speech team focused on ways to minimize the need for users to have to always say “Hey Google” to interact with their devices ;)
Reflecting back on my previous launches, and taking stock of how I think through things now, I realized that I always take the same approach to successfully building new products when taking a technology first approach. This approach also helps me to avoid the easy-to-fall-into trap of a solution looking for a problem.
Coming Up With A Concept
Immerse yourself in the Technology
Get familiar with the technology. Play with it. Build something with it. Read papers on it. Follow people & companies innovating and leading the breakthroughs in the space. Form an opinion. Things I find helpful to ask myself:
What’s possible today with this technology out-of-the-box
What’s possible today with a value add layer that I/my team would be able to add
The real goal here is to find something that is unique to you/your team – something that others wouldn’t be able to immediately copy
What’s likely possible tomorrow – who is going to build it
Others – how long do you think it will take? When it does happen, can you then add a value layer on it?
You – if you started today, is there anything stopping you from achieving it?
Expose yourself to new Ideas
Do new things. Make new things. Talk to new people. Go to new events. Read about new things. Open yourself up to the opportunity for new ideas. Ideas can come from the most unlikely of places.
Applying Technology to Ideas
The more you become familiar with an emerging technology, the more you’ll start thinking about how to apply it to your everyday experiences; and the more experiences you open yourself up to, the more ideas you’ll come up with.
Your goal should be to get to a point where it feels second nature to think about interesting ways to solve everyday problems by applying technology to them - consider this the “judgment free brainstorming phase” where more ideas == better. With that said, please know that most of the ideas you come up with won’t be great - in fact, they will likely be terrible (just because the technology to create lab grown diamonds exists doesn’t mean you should start a company focused on making kitchen knives out of it - even though knives that never need sharpening is a fun thought…), but that isn’t the goal right now. Your focus at first should be to grow and strengthen your idea generation muscle so your brain is primed to always be doing this, because occasionally you may actually strike on something worth thinking a bit more about.
I often refer to this phase as “technology in search of a problem to solve”. While this is an important step in finding something new to build, I also want to stress the importance of validating it, because not all ideas are created equal, and just because you can build it, doesn’t mean you should (unless it’s a passion project - then go wild).
That said, once you do come up with an idea that you actually think has some teeth behind it, it’s time to really think it through and validate whether there is something there worth investing in. I’ll talk more about this in next week's post.
Where To Apply Technology First Product Development
While I’m a strong believer that technology first product development can lead to building remarkable things, it doesn’t work for all situations. When you are following principles of this approach, you are likely to fail in the first iteration (and possibly even the second and third). As such, this method is best suited for situations in which it is OK to fail. In fact, the long-term gains are often better built on the back of these short-term failures – iteration plays a key role in shaping these types of products.
When It Works
In particular, I find that this approach works especially well when:
You work for a big company like Google, Microsoft, or Amazon and you can fail forward.
You are in a startup and you need to hit a home run. A strike out is OK in pursuit of a bigger goal.
The technology is so groundbreaking and you can't miss out on the opportunity that has just opened up.
When It Doesn’t
Conversely, this approach isn’t well suited when:
You have a product that is on the precipice of Product Market Fit (PMF) and you only need incremental gains to satisfy user needs.
You have a clear list of prioritized user needs and an easy way to solve them using existing technology and methods.
You are in a startup/situation where you need more of a sure thing and you can't afford to fail.
love the image!