Moving product forward

In product, we risk getting bogged down in all the what-ifs, questions about possibilities, uncertainty.

When you're designing a product, you only have the limited information in front of you, combined with all that world of unknowns.

And there's only so much you can glean from those unknowns before you're forced to act and test, ship and learn.

Years ago, I worked with a CEO on a new onboarding flow. We were testing out pages for the flow, and for one page in particular, he suggested a button that lead to a 404 page.

That wasn't because of an intent to deceive anyone or design dark patterns.

We just needed to know, with our limited constraints as a team, whether we even understood the desires of people on our platform. If nobody clicked, that in itself would be a learning opportunity.

We still designed out the flow behind the button—and it turned into a success. But I've often remembered the example; what mattered versus where we put our effort.

Don't focus to infinity on the steps behind a button if you don't know whether the button provides value.

That's not to say we shouldn't care, that we shouldn't focus on delightful experiences for our users, that we shouldn't agonize over the details.

But without understanding who we're building for, what problems they're hoping to solve, and how our software makes their lives better, we're shooting in the dark.

So, as we build great products, we require a mix of wisdom, uncertainty, and awareness of the people we're trying to help.

Sometimes we can get around this by dogfooding, but the rest of the time, we just need to get close to the user and feel their pain, see their desires, and make software to help them.

I've seen too many teams get bogged down in all the technical questions, options, perfecting and polishing tiny details, while losing sight of who it's for and whether anyone will even care.

I'd rather my first baby, the thing I ship into the world, be a bit messy and uncertain—as opposed to perfect but never seen. If I had to choose, I'd always pick the former.

So where does polish fit in?

We've all used poor products, bad designs, software that felt like it was never intended for the real world.

I'm not saying that we should be responsible for more cruft.

But rather that we should ship quickly, learn fast, and modify as a result of real-world experience and hearing from our users.

We should not make something perfect before it sees the light of day, but we also shouldn't allow horribleness to make lives miserable for the unlucky folks who are trying to fill out a form that their hopes and dreams depend on.

It's a balancing act, but I'd lean toward moving fast and learning through empathy.

I remember one team I worked with years ago. We built out a beautiful design, created a fantastic flow, and saw from our users—through qualitative interviews and quantitative data—that it was successful. We spent months agonizing over every little detail, went through all the proper rounds of design and user feedback. And we succeeded. The metrics showed that we'd made a killer part of the app.

But then 75% of the team had to be let go because of larger problems with the company needing to make money.

I've thought about that a lot. How we made the perfect design, did everything right, but the company tanked.

In hindsight, I wonder if we could have used those months to make more money, to move faster on the product, to prove a path toward profitability—instead of expecting an unlimited runway to build delight—to move fast and ensure that we were solving the needs of people who were willing to pay.

I've worked with teams who only care about one side or the other.

From my perspective, from the scars I bear over all the years, I'm looking to figure out which we're leaning too heavily on and where we need to change things up.

You'll almost always see me opting for the side of moving quicker, learning faster, shifting and hearing from the market.

It's not that I don't care about quality and aesthetics—great UI design is the foundation of the best products out there—but sometimes we need to ensure we're building the right thing before building it right.