One of the most enduring myths in the product world is that great products result from listening to your customers (or prospective customers). But just as Jeff Bezos said in his latest Shareholder Letter, “No customer ever asked Amazon to create the Prime membership program.”
If you’ve read any of my material before, you know that’s because with technology products, a) customers don’t know what’s possible; and b) customers don’t know what they want until after they see it.
The truth is that customers are consistently not the source of true value creation and innovation. Of course, that doesn’t mean that we ignore our customers; quite the contrary, but it does mean that we must look elsewhere for the source of true innovation.
So then what is the source of true innovation? While there are many, for the clear majority of disruptive innovations that I get the opportunity to witness, the answer is the engineers.
Many of you have also heard me say, “If you’re just using your engineers to code, you’re only getting about half their value.”
In this article I’d like to dive deeper into how strong product teams actually utilize their engineering talent.
The reason this is so important is because it is so strikingly different from how most teams leverage their engineers.
So many people think it’s the job of the founder or the product manager to decide what to build, and it’s the job of the engineers to build it. That sounds straight-forward enough, but it’s a sign of a mindset that rarely leads to truly disruptive products.
But first I want to make sure we’re all on the same page here about technology-enabled innovations.
I’d like to share a bit of the back stories behind several of the well-known innovations of our time, and how they were inspired and discovered.
Amazon is one of the most consistently innovative companies in the world. I could cite dozens of examples just from them.
One major innovation that is already quite successful but in my view is just the start, is Alexa. But as is so often the case, this wasn’t the result of some grand plan and strategy; rather, it started with the relatively humble Echo as a simple, voice-controlled music speaker.
But one of the engineers saw the potential of this technology, and created a prototype where the speaker could serve as the voice controller for a streaming TV device.
It was one of those defining moments for the team, and the prototype enabled people to see the potential of the device and service as the hub for the smart home.
As you probably know, Alexa has developed into a full-fledged platform, with thousands of “skills” far beyond playing music.
OK, Amazon is awesome. But what about innovation in old school companies? Disney’s Parks have been going for more than 50 years. It’s at the heart of their ecosystem model.
But by 2011, they ran the risk of becoming a victim of their own success, as long lines and crowds in parks were impacting return rates. The truth is that going to DisneyWorld was becoming less fun.
So Disney assembled a team of technology thought leaders and asked them to “reinvent the vacation experience, and keep Disney relevant,” which became known as Next-Generation Experience (NGE).
This new vision would impact everything from how guests enter the park, plan their day, pay for food, unlock their hotel room door, get personalized treatment, and more.
They built a discovery lab behind Epcot in Orlando. They built prototypes of an RFID-based wearable device, which became known as the MagicBand.
As you might imagine, this new world depended on updating a very old infrastructure, and Disney invested on the order of $1B in a new digital infrastructure for their theme parks. So in addition to leveraging technology, large companies also need the leadership and courage to make some big bets.
Customers didn’t request a MagicBand in any sense, but rather the designers and engineers saw the customer frustrations, and leveraged technology to reimagine and reinvent the guest experience.
If you haven’t yet had a chance to test out this new experience for yourself, I hope you give it a try as it’s very impressive and you can see how it has established a platform for many future guest experiences.
Google Translate has been one of Google’s less visible services. It’s been around about 10 years now, but it has grown steadily to the point where more than half a billion people around the world use Google Translate every month.
While the service has been able to grow along with Internet access, especially via smart mobile devices, around the world, improving the quality of translation has been much harder to achieve. For most of it’s life, most people would characterize Google Translate as “better than nothing.” But this wasn’t for lack of trying. The team had plugged away for nearly a decade on quality, yet this has proven to be an extremely hard problem, and in truth the improvements were relatively minor and hard even to perceive.
Yet that all changed this year. The team made more progress in improving quality of translation in the last year than it had made in the entire decade prior.
What changed? Google’s engineers realized that there was a new, enabling technology that had the potential to dramatically improve the quality of the results and the experience for users. For those that don’t know, this is an early application of machine-learning technology.
This is a fairly pure example of leveraging technology to create a dramatically better experience. In their case, they debuted the new technology without actually announcing it to see if users would perceive the improvements on their own – which they did.
Google is applying this new enabling technology to many of their services, as are many other strong companies.
The iPhone has been talked about by me and many others for years now, but the initial iPhone effort is an extreme example of customer-inspired but technology-enabled disruptive innovation.
What a lot of people don’t know, however, is that when the iPhone was being designed, the smartphone leaders of the day – Blackberry, Palm, Nokia, Motorola – these companies were all hard at work on their next smartphone, but instead of using their engineers the way I’m describing, they were busy conducting focus groups.
Many people think he iPhone was the first touch-screen based phone, but it wasn’t. The Palm Treo was very popular at the time, and it actually had a touch screen as well as a Blackberry style keyboard, although if you had one of those devices like I did, you know the touch screen was pretty awful. So what do you think the focus groups said? They said to lose the touch screen.
But of course Apple knows that’s not how you create disruptive products. They saw the potential of the technology and worked hard to create a device that leveraged the technology to serve customer needs much better than any customer (or even most competitors!) could have anticipated or had known was possible.
So you might be thinking you need to be a Google, Amazon, Apple or Disney to innovate like this, but that’s not at all the case. I just picked those product teams because you know them.
On the other hand, Workiva is a company you’ve almost certainly never heard of, although they have been extremely successful growing from early startup to successful public company in just a few busy years. They focus on a very under-served type of customer – the finance and accounting people at nearly every large public company.
These people consistently work some of the longest hours in the company and it’s largely a thankless and unrecognized effort because the rest of the company views this as overhead. But the founders of Workiva met some of these people, saw their very visible pain, and realized that they could dramatically improve their lives.
There were already several other enterprise software providers for this market, but most enterprise software companies are terrible examples of best practices, and they were literally building what their customers were asking for.
In contrast, the team at Workiva was very strong at technology, and they reimagined the solutions. They made very early bets on a few key enabling technologies and trends: cloud infrastructure, and a rich and modular front-end system for very interactive, office-like apps completely on the web.
It’s worth noting that they also believed that leveraging state of the art technologies would help them attract and retain top engineers, which would then allow them to continue to provide disruptive and truly innovative solutions.
This focus on truly taking care of customers by providing leading-edge, technology-powered solutions has resulted in NPS scores higher even than Apple – which is unheard of in the enterprise software world.
Keys to Leveraging Strong Engineers
So hopefully you can see the very real value in using your engineers for much more than just coding. What I’d like to talk about now is how to actually engage with your engineers so that you can start getting this value.
But first it’s absolutely critical to understand that table stakes for a strong technology product company is to hire strong engineers that are passionate about your vision. This is absolutely not something you want to outsource. You need missionaries not mercenaries. To be blunt, without that you have little hope of true innovation.
But fortunately most serious tech companies do have strong engineers. They’re just not utilizing them like they need to.
Here are my six keys to leveraging strong engineers:
1. Provide engineers business context
Your engineers need to understand the business context. So many CEO’s and product managers think they need to shelter their engineers from the ugly details and angry customers. Nothing could be further from the truth. These are the people that will save you. But they need the context. So share with them the vision, strategy, analytics, business goals, contractual requirements, and legal issues. Anything that might impact the product. They can handle it, and they will appreciate it.
2. Connect engineers with customer pain
The magic so often happens when the actual engineers are able to witness the customer pain first hand. Very little is actually more motivating to an engineer. They truly want to help fix that pain. Again, you’re not there to ask the customer what they want built. But rather, observe them using (or trying to use) your new prototypes or your current product, or whatever they are using today. Your goal is to understand if the customer can figure out how to do what they need to, and if they love this solution enough to buy it (or more likely, all the reasons they might not buy it).
3. Understand constraints vs. requirements
Lots of people in the company as well as your customers will try to “help” by providing the engineers “requirements.” This is not helpful. Requirements are rarely truly required. Rather, the job of the product manager is to identify the underlying constraints – legal, financial, sales, marketing, manufacturing, etc. – and then providing the engineers with these constraints. The result is significantly more degrees of freedom for the engineering team in solving the underlying customer or business problem.
4. Give engineers time in discovery
So many teams are essentially running like a little software factory. Product manager loads up a product backlog and the engineers constantly strive for improved velocity in implementing that backlog. It’s beyond the scope of this article to talk about all the reason this is not how good product companies work, but it is key to realize that you must give your engineers some time to prototype solutions and test them with actual customers before deciding to spend the time and money to build an actual product. Giving engineers some time in discovery is easily one of the best ROI things you can do. Most experienced engineers will tell you that a few hours including them up front can save weeks and month of waste later in the cycle.
5. Measure product team as a whole
Some teams make the big mistake of measuring engineers by one yardstick and product managers by another. This shows up as a common problem with OKR’s, where the engineers have one set of quarterly objectives and key results, and the product managers another. This is exactly the wrong approach for product teams. The team needs to be exactly aligned in terms of their work.
6. Competent and confident product managers
Finally, everything here depends on providing the engineers with a competent, technology and business savvy product manager or co-founder. The product manager brings deep knowledge of the customer, deep knowledge of the data, deep knowledge of the industry and deep knowledge of the many aspects of your company that impact the product – sales, marketing, legal, finance and more. The product manager also needs to have the confidence to be collaborative with their engineers. Strong product managers actively engage and seek out the opinions of the engineers versus feeling like they have to know everything. So many teams don’t get the value out of their engineers because they don’t provide the team with a capable product manager. Just note that if you think the product manager is someone with a product owner certification, you almost certainly have this problem.
Now it’s important to acknowledge that not all engineers are interested in engaging at the level I’m describing, although it is fairly common that this level of engagement is necessary to achieve the level of a tech lead. That’s fine. But you do need at least one engineer on every product team that is willing and able to engage at this level. And I will also admit that my favorite product teams are those where every engineer is this engaged, but that requires a culture where this is highly valued and specifically recruited for. It’s the best example of a team of missionaries.
So if you are not seeing the level of innovation your business needs, I hope you’ll give this way of working a try and see for yourself what a team of missionaries can accomplish.