Hacker News Reader

Comment by fny | Hacker News Reader

I'll warn against getting way too focused on this as an early company.

Getting something up and running is often waaaaaay more valuable then achieving Stripe level UX from the outset, and then as time progresses you must make a conscious effort to improve. Remember, Stripe has been an app for about a decade. That's a decade's worth of learning what users care about and what details matter. And clearly that's a decade to polish a product to near perfection.

A trap I've fallen in myself, and I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about. Often you'll only learn that by having a product that works and customers need from the outset.

View on HN

That's fair and valid, but shifting your culture from one that's laser-focused on shipping features that work to one that cares about shipping polished features that delights users definitely gets exponentially harder as your company scales in size.

The sweet-spot for making that transition is essentially as soon as you've found product-market fit, no later and no sooner, and missing that sweet spot even a little bit can make the transition very difficult and very costly. But the dilemma is, as most successful founders will likely tell you, we're only good at identifying product-market fit in hindsight, long after it happens (and it may never actually happen).

I've worked at plenty of companies that pay lip service to wanting to ship polished features that delight users while still overwhelmingly shipping features in a very utilitarian, timeline dominated fashion, long past the point where they've demonstrated product market fit.

As with anything in product/engineering/design, it's all about tradeoffs and striking the right balance, and where the right balance stands will always keep shifting under your feet as you make progress...

There is one way to make sure the product improves after shipping a quick-and-dirty first version: dog-fooding.

Be a user, for real. Many seem to think that just using the product equals dog-fooding, but real dog-fooding is when you can honestly say you get real value out of using the product. It is when you'd pay to use it.

When you use your own product and gets value out of doing so, you have true customer perspective and your needs are aligned with your customers needs.

> A trap I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about.

That's odd. The point of focusing on users is to discover what users want. If you're not doing then you're not really focused on users.

But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.

Also, +1 to the parent comment. I worked at a startup where we made exactly that mistake - we delayed releases until it met a high standard of UX - took us more than couple of years. By this time, competitors that built a _much_ crappier product got userbase, and hence funding, and then used that to get their UX up to par (sometimes they wouldn't even have the features, they just faked it). We realized our mistake, adapted and stayed in business - but it was a difficult and painful process.

So basically - first get things up and running FAST, then worry about polish and laser-cut UX.

> But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.

If these two things are not equal then you're doing it wrong.

I think the point is you can easily get so focused on making the experience "delightful" that you work on things that would delight you, but that your users actually don't care about so much. And you need to take a step back, build something functional but not necessarily completely "delightful" & then figure out what your initial users actually do care about and iterate from there

I think of it like listen to your users, but don’t do everything they ask. Use your judgement to make sure it aligns with your goals, and hopefully you have a goal beyond ‘make monies’.

Additionally, think about why they're asking for a certain thing, and whether their request is really the best way to solve the underlying problem they want solved

“Treat your users as you would a class of pre-school children. If they’re all screaming for a snack you don’t necessarily give them one, perhaps a healthy lunch would be better for the underlying need.”

I don't think pre-school children are the only people who are poor at recognising or expressing what they really want, I think that's a fairly universal thing. It's very easy to get an idea about what the solution should be & make a request based on that rather than basing the request on the problem you're facing.

A good analogy I heard recently (more to do with planning your own projects than requesting stuff in other people's, but I think it still works): imagine you have a large patch of grass and it is taking too long to cut. There are a couple of ways to define that problem:

* I need a better lawnmower

* I need a better way to cut grass

The first locks you in to a particular solution (lawnmower), but there may be a better possible solution out there, and the second statement opens it up a bit. So bringing that back to the user request thing, if your user requests a better lawnmower, make sure there isn't some better way to have the grass cut instead.

Reply on news.ycombinator.com