The Most Effective 1% in Product Development

(making use of what you already have)

I’ve decided to write reflections on my work as I go. It’s the start of an ongoing effort to poke both holes and fun in my thinking then and now. And hopefully come out with a better understanding of how we work, and more often don’t. Or at least that’s the bullshit mission statement.

When I left college I seemed to consider the hard engineering and design work to be the only real work that was going on. Though I probably just didn’t have the confidence and data to trust my deeper instincts. So I spent 90% of my time in my first job building big “release features” and then when I wanted to mess around for a few hours I’d do the what-I-consider-silly work. However I think it’s often these tiny things that made better use of my time and of everyone in the companies work. As I got more confident I grew the deep desire to stop constantly building new big release features and preferred joining the dots more clearly between all the features already deployed. Telling a joined up story out of some very contrasting threads.

1) Help users understand what they’ve already got

Several engineers including me spent months and months working on this big new feature (alerting), refining the complex code and interface interactions. We built and tweaked, we soft launched and then we hard launched. A few big customers relied on this alerting quite quickly, but strangely enough there was not a lot of mid level usage (i.e. people using it for 4–10 critical alerts, what we considered it most useful for). It was a top level menu item, everyone was included in the mail campaigns for it and it was included in everyones payment plans and was bloody useful, so why weren’t they using it! People just weren’t setting up that first and second alert, and making it more usable wasn’t fixing it. Eventually we paused improving the alerting interface and we fixed this bigger issue by tackling… the home-screen.

The home screen for the app had that SASS problem where they’re often just a stop off until you launched the more specific part i.e. no focus. So, in a bid to just get something tested quickly, I knocked up a a few dozen quick iterations for new version of the home screen. One half of the screen was now based on constantly informing the user what they had paid for and used. Below you can see the before and after.

Original Top Row — Jumble of random functions
New Top Row — Clear indication of what you’ve actually used and what’s possible

Now this feature had been out for months already. However after this 5 days of work, in a matter of a few weeks, there was an increase from only a few big customers using alerting properly to adding more than 50/60 medium sized customers using the feature properly as well. A few days work to get customer reach for what was more than a years combined engineering work. This is what reinforced the knowledge that time spent on the little things was often the best way to spend a few days.

2) Being proud of our work

If you’re actually proud of your work then you should be as confident as the biggest players are!

Since it’s inception the app I was working on had lots of self built integrations with 3rd party sites. Yet there was no page that listed all these plugins/add-ons/integrations as they were considered too disparate in functionality to be considered any one of the above. Or some were too simple to even be listed anywhere!

Yet when we actually took a look at Slack’s or Heroku’s add-ons, they were as disparate in functionality as ours! They just had the confidence to group them anyway as it’s just easier for customers. It didn’t matter if it wasn’t exactly an add-on, the user would come to that page to see if we had anything like that, so it should be there. So… a few days later we launched an add-ons page! Although this was not a new engineering feature it gave the whole company a language and confidence to be clear to our customers of what we build and what we support. This showed off so many corners of HG (and accumulated years of engineering work) with just a few days frontend hackery.

3) Finally, talking to users about old features as well as new ones

Soon after the add-ons page project, I realised there was lots of useful older work, including add-ons, that people might want to use but have never considered looking for. While email was great for new feature rollouts, it was less suitable for spamming the user about these older features.

We were obviously already tracking what customers used and even sometimes could figure out what they should be using. So a few days hacking later and we had soft messaging on the homepage chatting to the user casually (but not overly-friendly) about all the things they hadn’t used yet. It’s small, doesn’t get in your way and uses the tone of “you’ve already paid for this very useful thing”; not sales-y but helpful.

Give precedence to refinement rather than new features

The lesson here for me has been to have joy in my work, thus I’ll truly desire as many of the customers use as much of it as I can. And from the data you can often see these small links are more useful than another “big feature” that most of your customers don’t find. Most of this can of course be found worded differently in “Lean X” or whatever, but learning a lesson yourself beats just reading about it 20 times.