Creating Innovative Product Teams

My manager asked me recently to sum up some of the lessons learned in the past 16 months as we spun up, then executed, Project Shelby. In an industry where creating a net new product can take years, getting from nothing to something in less than a year-and-a-half was a journey that had it share of bumps in the road -- but ultimately proved to be a destination worth the pursuit.

As I tapped out my response in Slack, it occurred to me that it would have been nice to have had some of these things written down before we started. So presented here are my top 5 lessons for innovations teams. I'd love to hear from you about any I might have missed.

Lesson #1: Ideation Requires Implementation

Said another way: you need an implementer on the team before the project kicks off. You can't innovate just by thinking innovative thoughts; you need to prototype and try things out. If you find yourself sitting in a room with a bunch of business people who've never written code before, stop the meeting, find a developer, and reconvene when you have the correct skill-set in the room.

If you want more than just my recommendation, look at some of the big names in tech. Bill Gates and Mark Zuckerberg both wrote code to explore their ideas. Steve Jobs wasn't really an engineer himself, but at the beginning he had Woz to push back on the reality distortion field and shape the vision into something tangible.

Rapid prototyping lets you "fail fast". Try ideas out before you launch an expensive project to execute on them. You'll be glad you did.

Lesson #2: Separate the Things That Need to Change from the Things that Don't

Building hardware or infrastructure is hard and expensive. Don't start with that if your idea is totally new. Even if it constrains the idea, use existing platforms to test new theories -- you can do a lot in pure software these days, so start there. This physically de-couples the stuff that will need to change fast from the stuff that won't. Some projects are going to require hardware innovation, but do that part after you know exactly what you need and why. The very first Apple touch device prototype was a pane of glass tethered to a bank of PowerMac G5 towers. Obviously that wasn't what they shipped, but they started by focusing on the software because its cheaper and faster to make changes in code when you learn something new.

Abstract out the things you're still learning to a surface where you can iterate faster.

Lesson #3: Start With the Customer - But Don't Be Limited by Their Imagination

The Henry Ford "faster horse" anecdote is cliché now, but its worth pointing out that Mr. Ford probably didn't mean we should ignore the customer. Rather, we should go beyond the "spoken need" and look for the "felt need." The customer may not have the vocabulary or imagination to describe exactly what they want -- that's what you're there for -- but they are expressing a desire or need. Ask questions that help you get beyond their words and tease out the real requirement.

As an anecdote, when we were dreaming up Shelby, we spoke to a lot of customers. One of them told us that they wanted to sample every point of data in their operation and shuttle it to a remote data center at physics-defying speeds. We could have responded to that spoken requirement and started dreaming up new ways of doing super fast data collection, but on further questioning we learned that they were trying to get that data into a remote algorithm that they hoped would help predict machine failures. Turns out there's a much easier way to meet that need, but if we hadn't asked why, we would have missed it.

At Amazon, we often used the "5 Whys" approach to find the underlying issue for a given problem. Couched appropriately, this can be employed with customers or potential customers too.

Lesson #4: Physical Proximity Foments Collaboration - Protect It

This was a tough one for me to accept. I'm an introvert, and I enjoy my alone time. In fact, I feel like I'm most productive when I'm in my cone of silence. But in the early stages of a project, team members need to put their personal preferences aside, and be present with each other.

Once the vision is set and the team is formed, only implementers should be involved. They should sit together, and they should sit apart from the regular business.

Skype meetings, even with video, do not allow for spontaneous problem-solving. And monthly progress reports developed with a specific PowerPoint template and presented to a room full of people who aren't actively contributing to the project themselves damages the team's pace and rhythm. Intentionally exclude the normal cadence and processes. Intentionally make room for the team to self-organize and self-manage.

Keep this up at least until that precious and fragile idea finds its footing. The definition of incubation is keeping something separate and safe until it has time to mature.

Lesson #5: A Product Owner is a Bridge, Find a Good One

An innovation project must iterate fast. The vision needs a champion who keeps each iteration moving toward the end goal. The team needs a sounding board against which they can test ideas, explore theories, and demonstrate each iteration to. A good Product Owner is part high-level architect, part implementer, and part customer and business advocate.

The Product Owner is a servant to the team, taking the brunt of both customer demand, and engineering frustration against a deliberate limitation of scope, time and resources that ensures only enough of a solution is built to test the theory. A minimum viable product is the art of compromise, managing expectations on both sides of the equation to provide something compelling while limiting risk -- so that, if the idea doesn't pan out, there's still an appetite from the business to try again.

None of these things guarantee an outcome. In fact a requirement for innovation is permission to fail: experiments should be sized just ambitious enough to market test a theory and engage an audience in an idea. The header image for this post is this fantastic diagram I found online years ago which I have posted in our collaborative workspace. It explains that a MVP is not just about feasibility (that's prototyping) -- instead it's a thin slice of what might someday become a full and mature product. I'd add that it must include a way to measure what works and what doesn't, so you learn and improve as the product evolves.

Innovate in small steps that you take quickly, and double down on the things that work.