Comment by zt | Hacker News Reader

Comment by zt | Hacker News Reader

Look, I know that the idea of being customer focused might seem trite, but I wanted to focus on one thing: it's the little things.

"What actually differentiates stripe from the rest of the bunch though? It’s the little things.Stripe obsesses over creating a seamless CX. Small annoyances in applications compound. A user might not churn immediately because you have a bunch of unoptimized functionality or crappy UX, but it’s a recipe to create a grumpy user. And grumpy users aren’t loyal users."

This is an idea I've been turning over in my head a bunch recently: the compounding effects of delighting your users. That cumulative innovation that comes from building for your customers....I sometimes get asked "what's the killer idea behind [company X]". But there isn't one big thing. There are many, many small things built on having a relentlessly customer-back attitude. You can't just copy the "idea", you have to copy the way of working and thinking. That's a lot harder.

Let's take Brex as another example. It's the segmentation, UX, marketing, rewards, underwriting, etc. It's each of those things broken up into a hundred subcomponents and iterated on. It's an entire ethos and operating model. That's cumulative innovation...not a single idea.

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.

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.

I have understood over years that, below listed things typically lead to "grand success" or "cults" [ tech or otherwise - but then, eveyrthing is "tech" now anyway!]

1. Enterprise readiness (in order of precedence: real business value [either brings money or saves good chunk of money], robustness, usability, integration capabilities, ease of on-onboarding, simpelr path to value-maximization. Good to haves: delightful user experience, great documentation)

2. Developer delight: The ecosystem (=> tools, platforms, training, autonomy, agency, motivation via empathetic management) offered to developers, in order to make them super effective, productive and efficient - to cater to the above listed. Note: "Developers" include Ops and Tech Support personnel too!

3. Customer delight: The above two leads to "customer delight" They see that the tool/solution clearly brings value, and that the support team is able to deliver the same as well - sustainably and happily.

This leads to a great win - for vendor and customer.

Building such an ecosystem is not a trivial or simple thing. Takes years, decades even.

In the end, that cutl gets formed - thanks to those ingredients that continuously keep "wow"ing the makers and the users. The "stuff" takes the limelight, but that's just proxy for the makers, their tools, skills and motivation.

This applies not just for software, but for many others! People value Toyota because Toyota's entire organization structure and inclination is on those lines - to 'drive' better value for consumers and their own people who offer'em.

You need both; you need a solid core, a reliable and fast service - both in the literal sense (e.g. back-end services) and in the figurative (your business process, so to speak), and on top of that you need to build a solid user experience.

And that's still not all, you ALSO need to do marketing and sales.

To take an example, there's about a bajillion 'todo' or 'notes' apps, I think because they are easy - simple data models, at the core. Because that is finished quickly, developers focus on the UI / UX, which is extra emphasized because they often live in the Mac / iOS atmospheres.

Some will do marketing on top of that, pretty landing pages, get featured in the app store and the low effort app news sites. But there's a lot (on HN for example) that miss out on that.

But that's just one highly competed area, there's not much you can do now to get a foot in the door - it's not a market "ripe for disruption" as the HN crowd likes to say.

Financial transactions on the other hand is really hard to get right at the core. Adyen is doing a pretty decent job there, I'm sure Stripe does as well, but they emphasize more on the UX and smaller customers. There's also others like Buckaroo, Icepay, MultiSafepay, and a couple others.

I think you might be missing the point the article was trying to make when you took the negative emotion which the author was describing (“annoyances”) and turned it into a positive one (“delight”). I don’t think you can simply say delight is the absence of annoyance, and that good applications are ones which delight their users.

Because while delightful interactions can wow your users and get them to tweet about your application, the mark of a great user experience is that it goes largely unnoticed by the user. You don’t notice a door when you walk through it; you’d only notice it if you couldn’t get through it. We only pay attention to tools when things go wrong; as developers we are keenly aware of this fact whenever we have to debug code which stops working.

A seamless user experience should actually be imperceptible to the user, and I’m not sure this has anything to do with delightfulness or juiciness or any of the other stretch goals UI people come up with. The fact of the matter is, not annoying the user isn’t as sexy, and boils down to competence (writing bug-free code) and consent (not using dark patterns to get the user to do shit they don’t want to do).

If you work in an organization where this isn't the norm-- do you try and change it, or is it best to move on? Sometimes, it feels difficult knowing I made one corner of the product great when there's glaring issues elsewhere, and my team doesn't have the bandwidth (or jurisdiction) to fix all of it.

If this is a result of poor execution then I'd stay and change it. If instead it's a result of a cultural or company vision that does not embrace focusing on the customer, their problem (not just your opinion of it), and working constantly towards solving the problem then you should bail.

I spent a lot of years in several companies thinking I could correct a bad vision or culture, and unless you're the CEO you can't. Poor execution of a good vision/culture is always correctable, although you should consider what is the root cause of that poor execution... often it's personnel.

Execution is key.

Mere "Ideas" are useless.

Reply on news.ycombinator.com