Shipping Isn't Everything

November 15, 2017

In late 2014, I had an idea for a product, so I spent all night putting the idea together into a pitch deck, showed it to my manager, she showed it to her manager and a couple weeks later, our CEO was presenting that idea during the company All Hands. As it turns out, a team of engineers in the London office, had a similar idea cooking on their side of the pond and were inspired by the All Hands. So, I decided to pack my bags and move to London to turn that idea into a shipped product.

A year later, I found myself going back home without a shipped product under my belt.

As it’s usually the case with these types of things, the amount of detail I can share on the project is not privy to a public post. But there a few lessons that have stuck with me:

1. Know when to stop selling

During the beginning stages of the product, we painted a North Star with very broad brush strokes. This was great to ignite people’s imagination for what the product could be. So much untapped potential! While the product could be anything, this also meant it wasn’t any one thing. Without a laser-focused definition, our idea lacked an opinion, a reason for being.

We became enamored with what the idea could be, not with what it had to be first in order to get to our North Star. As we dove into the specifics, we noticed that every stakeholder held a different version of the product in their head. We'd packed many hypotheses into it and struggled to narrow them down to a single one for the fear of losing buy-in from the stakeholders.

We fell in love with the solution, not the problem.

It became hard to discern exactly where our beloved solution had failed us —out of all the possible problems, which problem had we failed to solve?— and so, when it came down to it, the entire project was deemed a failure.

The lesson here is: narrow down the scope quickly and make sure everyone is aligned along the way as the product takes shape into a cohesive MVP.

2. Explore often and don’t share everything

Constantly exploring new solutions to a problem is the job. As you do this, it's important to have a core set of people to share explorations with, but avoid sharing everything with everyone all the time. Doing so can be distracting for the team and result in unproductive feedback.

It’s better to set up recurring meetings where you can give the team context on that week’s explorations and explain the themes behind them. The formality of the meeting will force you to be more deliberate about the thinking behind each exploration and provide context for your thinking while taking ongoing feedback from cross-functional partners. This will help everyone feel involved in the process and gain trust in your ability to make decisions and lead the design of the project.

Allured by a culture of being open and transparent, I failed to properly frame designs when sharing them. This was exacerbated when working remotely. Folks would see explorations without context and over time the project generated a perception of being unfocused.

The lesson here is: create a process for sharing your work with the team to create shared expectations and collective understanding.

3. Take your best idea and throw it away

One of the best techniques I’ve learned came out of a conversation with my manager at the time, Jonah Jones. He argued that by removing my best idea, I could become forced to raise the bar on everything else. This seemed unintuitive at the time, but it’s now become a key part of my process.

Jeremy Gutsche describes how award-winning documentary director, Peter Lynch, applied this strategy on his film:

In the 1980s, Peter was making an unusual film, titled Project Grizzly. The documentary features an eclectic man whose life mission had been the creation of a grizzly-bear-proof suit of armour. The man’s goal was to build the suit and put it to the ultimate life-thrilling test: to see if a bear would kill him or if the suit would offer enough protection.

Within a week, Peter recorded footage of the man tumbling down a cliff, setting himself on fire, getting hit by a speeding truck, and getting his friends to beat him with baseball bats. Bizarre.

The footage was leading to Peter to focus on just how crazy this man has become. However, Peter removed the most bizarre footage. This forced him to look beyond the concept of insanity to unlock a deeper plot: the man’s search for meaning.

Similarly, as designers we often fall in love with a key detail of a product that we think defines it and really brings it to life. This can take many forms, like a particular interaction, a smooth animation, or a beautiful color palette. This often clouds our judgement and we end up making decisions around that key detail. Many times during that year, I felt extremely passionate about a particular design decision and claimed that it would make or break the product. The truth is, if a product needs a single detail to survive, it’s likely a gimmick and it probably won’t stand the test of time.

The lesson here is: next time you find yourself passionately defending a design detail, try putting it aside for a bit and consider reintroducing it after you’ve solved the rest of the product problems.

4. A design leader is rarely the hero

Ideas don’t belong to anyone in a team — they’re floating catalysts that are borrowed, remixed, and recycled to enact action. Great design leaders gift ideas to the team and remove themselves from the equation. An exercise:

Say you come up with an idea… Eureka! You rush to your computer, whip out your design tool of choice then proceed to visualize it. After an hour or two, you take a step back, bring your fingers to your mouth and kiss them. “What a masterpiece!” — you say to yourself.

Then you run to your PM and scream: “I just had a great idea!” Strike one.

You show them your design. It perfectly captures your goals and values on what makes a great product. Strike two.

The PM then proceeds to tell you why this idea won’t work because it doesn’t match their goals and values on what makes a great product. So you argue for hours and leave thinking: “They don’t get me.” Strike three. You’re out!

Everyone is fighting their own battles and will apply a unique perspective to the precious idea we think is so obvious. That’s what makes working in a team so exciting! Knowing that an idea won’t come out the same way as it went in is part of the magic of working in product teams. This was something that I struggled with; the product was so close to me that I felt personally attached to it. As a result, I subconsciously fought to defend the perception that it was “my idea” which resulted in tension within the team.

I learned that, instead of presenting a solution as your idea, it’s best to try framing it as a solution for a problem the team has expressed in the past, built by combining pieces of different solutions from everyone on the team. In the case of a disagreement in your next discussion around a design solution, focus on creating harmony in the room, no matter how right you may think you are.

A united team temporarily heading in the wrong direction is much more powerful than a single individual who knows the right path.

Make sure all voices are heard and thoroughly considered and learn to describe your point by building on someone else’s point — even if it happens to be an opposing point. People respond better to ideas that come from a group rather than a driving singular force. If after doing that you still can’t land on an agreement, try using Cap’s sliding scale of giving a f*ck.

5. Avoid surprises

As a jazz musician, I fell in love with surprising the audience; building a pattern then flipping it on its head to gauge people’s reactions and win their adoration. This was par for the course and a big motivation for performing in front of an audience. However, this is rarely the recipe for a successful design presentation.

I now know that design leadership is often about planting seeds of an idea in as many people as possible, then encouraging them to complete the thought. It’s not about having all the answers, but providing the most opportunities for self realization within the team.

Actively work to resolve conflicts within the core team and make sure there is consensus before presenting ideas to leadership. This means having as many back channel conversations as you can before unveiling your grand idea to the team. Ideally, nobody in the room should be surprised during a design presentation — everything should feel obvious in retrospect.


Those of us who understand what goes on in the trenches congratulate our peers simply for shipping products, as if there was inherent value in getting something out the door — no matter what that is. However, many products fall short from that moment and behind them countless frustrated product teams may look at that time as wasted. I hope these lessons help you and your team navigate your next product and arrive at the finish line in a single piece.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.