whatbrentsay

I've frequently worked at or with start ups and young companies with products that are either entirely new or haven't reached product-market fit. The teams in those situations are generally focused on "shipping product" as quickly and as regularly as they can so they can better understand what needs to be built next. It's an exercise in narrowing the field until you're left with a domain that is (ideally) small enough that you can own. It's only after you've found your lane that it makes sense to double down—offer more features, increase performance, improve usability, and make it look impressive.

When the average person encounters a new, rising app or service, odds are it's beyond that nascent flailing phase. It likely has plenty to figure out, but by the time scale becomes a priority finding an audience isn't. The messy adolescence is hidden.

I'm fascinated with the balance early products have to maintain. How do you prioritize work for a feature that may not matter? How robustly do your engineers build it? How much do you allow your designers to labor over the experience and interface? The answer to these questions is a unique reflection of resourcing, culture, leadership, and money. It may be two weeks at a company that staffed up quickly but has a short runway because it doesn't have much money left in the bank. It could be six weeks at a company that has lots of money and knows reliability and ease of use are core to its value proposition.

The only consistent answer across all permutations is that what you release should be "good enough." It should work well enough to be reliably used by your users. It should look good enough to fit with your brand and reinforce its external values. It should be good enough for you to collect the data you need to understand how its performing. It should have lots of room for improvement because you were relentless about cutting out what was unnecessary. It should not be perfect. After all, you may learn in a month that no one uses it.

How do you get to good enough? I think the simple answer is to embrace iterative design. Get comfortable asking yourself "what's the least I can do here while still providing value?" The moment you open a product up to others, you give up the luxury of knowing exactly what should come next. Taking an iterative approach offers many opportunities to test the hypothesis without committing all the resources you have to a series of overlapping assumptions. Talking to users can be daunting but early users can be surprisingly generous to trade time for a chance to influence something that solves a problem they regularly grapple with.

Approaching early features as a learning opportunity puts you in a mindset where scrapping something outright won't feel like a failure. Discovering with certainty that your users don't want a thing is valuable. It will invalidate a host of related ideas and serve the goal of narrowing the field.

With so many beautiful looking and pleasantly interactive apps available, it's easy to forget how much further along they are in their life cycle when compared to a new product. That's why "good enough" doesn't get the recognition it deserves. A "good enough" approach is a sign of discipline. It's an acknowledgment of a willingness to move in the direction you need—even if its different than you expected—in order to offer a compelling product to as many people as possible.