Tiny Wins | Hacker News Reader

Tiny Wins

joelcalifa.com

312 pointstosh63 comments

The ideas here are: pay close attention to your user's actual experience with your product; nuanced experience fixes can have big collateral benefits; there's a way to do that in the context of everything else. All good, from my perspective.

The caveat is that the author in this case is not that different from his users, who are other devs. He gets their experiences. The magic trick for dev is putting yourself in your user's experience when they really don't think like you. Non technical, kids, accountants, whatever. You really have to drop your assumptions and forget your investments and just see things the way they do. Empathy rules, but I feel it is hard to codify that as a skill. There's a big leap before tiny wins.

EDIT- to add, the signals to look at first are user complaints, and user's efficiency on tasks with your product, aka usability studies. Empathy informs your takeways from that.

Good summary, but he's not a dev, he's a designer.

Like many designers these days, they’re absolutely a developer too. Look at their past work!

I'm definitely a designer first, so I see things through a design lens. But I think that taking the time to truly understand your users as best you can—whether you're a designer, developer, PM, support, sales, etc—is the first step to building a good product and being able to identify these high impact areas.

just to be clear, when I said you were a designer rather than a dev, it wasn't intended to denigrate you, just to correct the inaccuracy in the "other devs" phrasing.

from your writing, it was very clear that design was your priority, whatever other skills you might also possess. so I feel a bit vindicated seeing your username.

> nuanced experience fixes can have big collateral benefits

For me, little annoyances really stack up and make the whole experience a pain. I prefer to not have a specific feature at all, but have a great experience on what works, that keep finding little things that annoy me

+1 Insightful.

Also relevant: beyond IQ and EQ is the concept of "CQ" or Cultural intelligence, which is even closer to the skillset you describe.

Basically go see your users. I've seen countless instances where a 2 min walk in an office would have changed a whole service life (and even a whole population by ripple effect).

As a Product Owner who conducted a painful amount of interviews last month, the solution is to talk to and observe your users.

I'd highly recommend the Product Bakery podcast as set of great resources for learning more about how to develop great user interview/research skills, whether you work in Product or in design/development more directly.

I discovered the podcast after landing on Christian Strunk's blog (one of the hosts) and it's greatly improved my Product skills and mindset.

https://anchor.fm/product-bakery

https://www.christianstrunk.com/blog

(I am in no way affiliated with the podcast and/or blog other than having found it very valuable).

One of the dev failure modes I regularly see when consulting (and have fallen into myself, many times) is believing value is a function of effort spent coding. More of the latter means more of the former.

But it turns out customers don’t care how long you took to build the thing. At all.

There’s a lot of win in finding and plucking low hanging fruit - those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting.

Related to this if OP is reading, I’d love to be able to drag and drop and upload images into GitHub wikis the way I can into GitHub Images. Between those two changes and uploading to wikis you’d have my vote for employee of the month!

Also, just to add to that, customer also doesn't care about your code quality or the fancy new tech you used underneath. In early stage, it is all about getting stuff done fast, creating value, capturing value and repeat.

The business does however care about the marginal cost of delivering new feature improvements.

https://youtu.be/TQ9rng6YFeY

And of course, the devs often care about using new tech since it improves both their current enjoyment of the job and (often) their future job prospects

If you have a stable team, cost of delivering new features are quite low. Tech improvement comes at much larger cost.

Technical debt is the concept that some features of your existing product can actually make it harder to deliver new features. When to address technical debt is quite literally the decision on when tech improvement will be more valuable than the next new feature.

I agree with this, with your caveat of "early stage". Later on we have a responsibility to keep tech debt under control to a degree, even if that's invisible to the customer. (The side effect of faster development pace and higher quality later down the line will certainly be visible).

But in the early stages - I agree with you and tend to take the view that it's better to just throw something together and get it out there and being used quickly - irrespective of how bad the code might be underneath.

Get the system out in front of users, and delivering value to them as quickly as possible. You cannot beat the power of getting early feedback and validation of a concept.

For larger (higher stakes) projects this can be in the form of a "prototype" where the expectation is set that it's not a complete product. For smaller projects, fuck it, call it Version 1 (or a "beta" if you must) and get real people using it quickly :-)

Just be prepared to continue iterating from there.

As a dev I also often fall into the trap of "coding for coding's sake" - I love TDD, DDD, clean code, getting the right abstractions... and yes this stuff (when used appropriately) can lead to good maintainable code with low tech debt and easier feature development... but too often as developers we can end up losing sight of the business need and go too far up our own backsides with this stuff. Perfecting the codebase in the name of maintainability and controlling tech debt, when really it's often unnecessary perfectionism - or premature optimisation at least. Maybe that's just my own experience and I'm projecting - but I do see this quite often with even the best devs I work with. Actually more often with the devs that take the most pride in their work. It's a difficult balance to strike.

the customer doesn't care about your code quality or tech stack, until you're unable to do something like replace an ellipsis with an arrow because your tech debt has become too large.

The customer cares about the code quality when it turns their experience into a slow and bloated one... or not, unfortunately, since the age of webapps and Electron has desensitised most users from telling the difference.

In my niche this is reporting. We agonize for YEARS about what to do.

Just thinking in what I need to do for this do "properly", ie: I plan to make a language as the base!(https://tablam.org).

Eventually I just install https://www.metabase.com and thanks to sane table + view design the end-users are nearly support-free.

Thanks for Metabase... never seen that before, and looks like it could solve a similar reporting hole in my current project.

Out of interest, did you use the Open Source version. Embedded or standalone?

The open source + standalone. Most reporting (of the kind this is needed) is made by selected user with different needs to the main app, so it work for us.

Interesting. Thanks.

did you try apache superset? if so, any reason you went w metabase?

Have recently tried both, my guess is the "sane table + view design the end-users are nearly support-free" is key. Superset is way way more complicated and hard to understand IMO.

I don't know about that option. For metabase, was the UI that our support rep think easier to get ;)

Completely agree! Long ago I worked at a fintech startup that made a Master Data Management (MDM) solution for hedge funds. Usually people would log into the webapp, make changes to the data, and log out. Do it 10 times and it starts to get boring.

A couple of folks hacked together an Excel plugin that could make those data changes in bulk. Voila! Customers loved it!

The amount of happy customers we got for that weekend project was overwhelming.

The power of Excel is underestimated by everybody, except those that use it day in and day out.

> those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting

Oh 100% this was a major revelation in my career going from hobbyist to professional gamedev. As a hobbyist I would think "Yeah sure the units are spinning randomly on corners because I messed up the rotation math, but I can fix that anytime. I should be working on this yet-another-feature".

When correct process is to fix the biggest pain point: and surprise! There you go, the next biggest pain point becomes obvious. Repeat ad intinitum and you'll have polished yourself a commercial-grade game.

> There’s a lot of win in finding and plucking low hanging fruit - those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting.

Totally agree. A brilliant piece of wisdom!

These can be good new employee startup projects. Once around the dev cycle but not too complex. Early win, happy engineer.

I'm always impressed by people who are top dogs at self-promotion. These are small projects, small changes, but presented as best as they could, with as much fanfare and congratulations as can be achieved.

I mean, an arrow for data flow direction? It sure is better than a non-descript triple dots, but was it that non-obvious? The mileage he gets from this small change in this blog post is remarkable.

I constantly fail at this game.

> The mileage he gets from this small change in this blog post is remarkable.

I think that's entirely the point he's making! :-)

> I constantly fail at this game.

Me too.

It becomes much easier if you can see things through the user's eyes. Then you realize that the tiny change you made is worth talking about because it substantially improves the users' lives.

It's called the curse of knowledge :) https://en.wikipedia.org/wiki/Curse_of_knowledge

The best way to get better at the game is to know you have a blind spot. Once you do, then you can come with strategies to work around it. It takes quite a bit of work, especially at first - but like most skills, the more you make the effort to practice them, the less effort and easier they get to accomplish over time.

Whenever I am writing anything explanatory out now, I force myself to step back, and re-read it out loud as if I was reading it to a family member with zero familiarity of the subject. It's pretty effective :) Feels very weird at first, but actually physically reading it out loud is key - forces your brain to process it and not take mental short cuts.

To me your comment reads as scornful rather than impressed; that you think he is milking something undeservingly and self-servingly.

The mindset and writing style "I'm humbled that such a small change could help so many :)" is far more engaging than the writing style "so much fanfare for THAT, that was obvious I saw that ages ago because I'm not dumb".

"Low hanging fruit" is only there until someone has picked it all, then all that's left is the grind to get the higher fruit. This is something I see mgmt failing to understand over and over. A certain team comes through, does some small tweaks to get 10x throughput (over, say, a week). Then they're confused why they can't just get another 10x gain in a week.

First of all 10x on 10x is doing 9x the work the original team did

Presuming the team sorted the effort-reward ratio tasks, the only things left in the project will be harder than the first team tackled.

The effort-value matrix is a magical thing. We use it to prioritize everything at all levels of scale. Yearly initiatives, quarterly goals, what to do this week, bugs, new hires, bizdev prospects, technical approaches,etc, etc.

If people disagree on where a thing should sit in the matrix then a productive discussion usually ensues. If a thing is really valuable and really hard, we break it into smaller pieces. If someone's pet project is lower value than other easier things, we deprioritize it with no hard feelings.

It's crazy to me that the effort/value matrix is not a core part of tools like JIRA/Trello. Subtask[1] does a pretty good job with this though.

[1]: https://subtask.co

While this article focuses on a niche, tiny wins are a universally applicable concept. I think they are a powerful abstraction.

I recently finished "Tiny Habits: The Small Changes That Change Everything" by BJ Fogg [1], which talks about this in generality. The essence is that behaviors are a product of motivation, ability, and prompts. By keeping things tiny, we avoid the need of very high motivation, the need for very high ability, and devise easy triggers/prompts to get work done. It has been quite fun to identify tiny habits in my daily routine, I've collected quite a few and narrowed down on what works and what doesn't.

This is then applicable to software engineering, product development etc. One of Instagram's co-founder was apparently enrolled in the author's class, and therefore pops up as an example a few times through the book.

I've always ridiculed self-help books. This book does have a self-help flavor, but always concludes with precise actionable advice. By developing a general framework and a mental model around habits (think abstraction in usual software engineering terms), it does feel more controllable. Highly recommended!

[1]: https://www.librarything.com/work/23220746/book/198725553

The lack of arrow in the merge direction page was baffling (given that IIRC elsewhere lines were used to indicate change direction). Glad they fixed it.

What's missing in this article in talking about how little time the changes took ("This was a one-line code change that took a few minutes.") is if there was much consultation with designers/management/UX-people involved, and much testing needed after.

> The lack of arrow in the merge direction page was baffling

For what it's worth, it came from the fact that you were doing `git diff master...feature-branch`

Totally agree with you that the coding time is likely a tiny part of the total time spent. Tiny wins are hard to find.

Another blog post from GitHub on “paper cuts”: https://github.blog/2018-08-28-announcing-paper-cuts/

Canonical's Ubuntu "paper cuts" project from 2009 https://ubuntu.com/blog/paper-cuts-need-you

Totally agree - you can either spot those yourself by putting yourself as a user or listening to your customers. The other challenge is to get those tiny wins into the sprint when your PM can be clueless about the ROI on those..

While we're on the subject, if someone from Mac OS can please seperate my trackpad and mouse settings so the scroll natural/reverse is kept between for each device, that'd be appreciated

You may find this application useful: https://pilotmoon.com/scrollreverser/

It's so annoying when I have to open Logi Options everytime I want to use a physical mouse to get the scroll going right.

> The other challenge is to get those tiny wins into the sprint when your PM can be clueless about the ROI on those.

If the PM is clueless about tiny wins for the customer you should find a new PM. That's basically the crux of their job.

Looks like BetterTouchTool would solve it: https://community.folivora.ai/t/mouse-invert-scroll/1847

It is an amazing tool in general. Together with Alfred these are the two main apps that I use all the time.

Sometimes a tiny win can satisfy just one crucial customer. Once upon a time I joined a contractor development team with a strained relationship with their customer PM who a) represented the project to the wider organization and b) controlled the purse strings. This PM felt like the dev team wasn't listening enough to him or delivering enough.

My particular project had a simple web UI, and all the PM wanted was a feedback link added, and he was frustrated that it wasn't there yet. Although this was trivial and not critical at all to the application, I made sure to get that link up on the page - it was nothing more than a link to a feedback form or a mailto:, it was basic.

Anyway, the PM was super happy when that link showed up. It definitely wasn't because this was some whizbang new feature, or scratching some itch that had been annoying a lot of people. It was because the team showed that we were listening and responsive to him. That's a win, too.

This is the true spirit of UX. Thinking about how best you can improve the user's experience. Like many things, the meaning of the term has been diluted over time, but in this sense it's truly a beautiful thing.

Nit-pick: I don't like the language of wins [versus losses]. I get that people like short words that are associated with happiness and success, but the underlying messaging are that if we're not winning, we're losing, or that we "have to win".

In reality, failure should be normal, expected, and even desired, because if you're not failing, you're not trying new things or taking risks. You should lose sometimes. But success is preferred to failure, so I would prefer to get Tiny Successes through Tiny Improvements.

Consider this edit:

> Nit-pick: I don't like the language of Successes [versus failures]. I get that people like short words that are associated with happiness and winning, but the underlying messaging are that if we're not succeeding, we're failing, or that we "have to succeed".

In this context:

- Sports competitions have winners and losers, but arguably no failures. Silver and bronze are certainly not failures. The lost first place, but won second. Lost second but won third. Etc. Last place could easily have been competing against themselves.

- Grants/Charity Competitions have winners and non-winners. I would argue neither failures or losers.

Lots of nuance, but my point is that it seems like you have a bias that makes you prefer success/failure vs winning/losing.

I don't believe it's updated anymore, but there was an entire website dedicated to this.[1]

[1]: https://littlebigdetails.com

> That’s not to say that impact can or should be measured by the number of likes received (unlike, say, personal worth).

I'd rather say the opposite: impact can indeed be measured by number of likes; it shouldn't always, but it often is a good first indicator. Personal worth never can nor should.

He was probably being cynical on the "personal worth" addition.

This is close to what we called "magical moments" at HERE. Unfortunately, it doesn't seem like anyone really cared about them. The company was too focused on the one-hitter that would make us more appealing than Google Maps.

Tiny wins got me to switch to MacOS and never look back.

The similarity to the Eisenhower Matrix for task scheduling is apparent. The two of them would pair nicely in a discussion.

https://www.eisenhower.me/eisenhower-matrix/

I’d like to see which of my organization’s projects are currently failing their GHA build. Does anybody know how I can do this without clicking in to every single project?

Edit: I know this is sort of off topic, but it’s similar to being able to see the build status from the favicon.

> That’s not to say that impact can or should be measured by the number of likes received (unlike, say, personal worth). But the individual responses tell a story of how meaningful even the smallest tweak can be to your users.

Depends a lot on how you define "impact" at the end of the day. Did such measures make GitHub preferable over other platforms? It's not obvious.

It's easy to mistake the visibility of solving an issue with its impact. Sometimes they have no impact at all yet they seem important.

Small wins like this aren't often the reason for someone switching, but they can absolutely affect customer retention. Removing small frustrations can help to avoid users leaving your product, or be the boost needed to bump someone up to a paid plan.

As a standalone feature there's no significant impact, but changes like these can gradually improve the user experience until they become greater than the sum of their parts.

Yup - friction. Those who figure out how to reduce or eliminate it become fabulously wealthy (/waves at Apple).

To find tiny wins make your programmers use the product daily.

Simple fixes for pain points will appear magically :)

> low effort high impact

is something to cultivate, probably the most important factor in my not so experienced eyes

Kaizen + Genchi Genbutsu. TPS is so valuable.

Reply on news.ycombinator.com