Shipping Isn’t Everything
Lessons learned after a year working on a product that didn’t ship.
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 found that even in those instances, there’s always a learning or two we can take with us to our next venture.
In November 2014, I spent a month with a small team fleshing out an idea I had earlier that year. By the end of that month, we realized the idea was much bigger than any one of us had anticipated and we needed more than a month to see it through. And so, I decided to spend a year in London dedicated to making that idea a reality and building a team around it.
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 Medium post. But there a few lessons that have stuck with me and made the entire experience worthwhile.
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 —it could be anything. So much untapped potential! While the product could be anything, this also meant it wasn’t any one thing. Without a laser-focused goal in sight, our product 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 there. As we dove into the specifics, every stakeholder held a different version of the product in their head. We packed many hypotheses into it and struggled to narrow it 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.
As we encountered new problems, 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 the entire project was deemed a failure.
The lesson here is: we should’ve narrowed down the scope faster and made sure everyone was aligned along the way as the product took shape into a cohesive MVP.
2. Explore often and don’t share everything
Constantly exploring different ways to approach the problem and sharing those explorations with others will help the team understand the best direction to move forward. As you do this, make sure you have a core set of people you can share explorations with, but avoid sharing everything with everyone all the time. This 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. Many folks would see explorations without context and over time the project generated a perception of being unfocused.
The lesson here is: create a process around 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 preposterous 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 different 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 that one detail to survive, it’s likely a gimmick and it probably won’t stand the test of time. 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.
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.
I hope these lessons help you navigate your next product and help the team arrive at the finish line in one piece. Perhaps most importantly, make sure you’re having fun, are being challenged, and grow personally as you sprint towards that ship date. No matter how impactful the destination, it’s not worth it if you’re not enjoying the journey.
If you’d like to chat about this or anything else, please say hello on Twitter: @gabrielvaldivia.
This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
