Liam Nugent’s website

Keep the show on the road

2026-09-21T00:00:00Z

Products and features exist to try to create or influence an outcome.

Search: to sell ads. Social media: to sell ads. AI: to take over your life and kill all humanity.

(When you look at it like that, bring back the bad old days of sponsored links. All is forgiven.)

But seriously. If we go with the product lifecycle doctrine, build is only the first part. It’s also where most product people live and work and get stuck, sadly.

Build should be the short bit.

Once it’s built, and once your features are starting to be used, there’s a question you should strive to ask as quickly as possible.

Persevere or pivot?

Then you keep asking it, until the product is retired. It’s a close relative of the question Jason Fried asks about anything he’s finished — would I do it again? Same instinct. You’re just asking it about something that’s still running.

(Interesting side-bar. We say a product “is retired” rather than a product retires. It’s something that happens to it. It doesn’t just happen.)

#But… entropy

After you build, after you finish creating the software and it’s doing what you want it to do, does the job stop?

Of course not.

Because… entropy. I’ve been here before on this very site — 100/100 across the board when I launched it, and then the scores quietly dropped without anything being consciously changed by me.

Even if it’s the most perfectly written piece of software, unless you maintain it, it will degrade over time. OS updates will come around. Security vulnerabilities will appear as the libraries you depend on are exploited. Life happens.

And neglect sends you a bill eventually. It once took me four hours to get back to the position where I could write a post. That’s on a personal site with one user and nothing at stake.

The main point I want to make is that the vast majority of features and products either don’t make it to the operating phase. Or, if they do, they are often neglected.

So who is thinking, talking and writing about how you keep the show on the road?

If you are, or if you follow anyone who is, please email me a link. I’d love to hear about it.

#Managed decline

On the other side of the fence are the people who are essentially doing ‘product’ work, but it’s hidden underneath the guise of customer service or ops management.

The catch with that organisational model is that they have no access to get changes made.

So they essentially preside over managed decline, as the shiny thing they were haughtily given by the real product people either naturally degrades, or what customers really need shifts over time.

So what’s a guy to do with that situation?

Chances are that you’re not going to manage to rebuild the whole organisation in one quick move. So you need to do it brick by brick.

The secret is that the customer service people, the ops teams, need to become your best friends.

They know what’s needed. They know where the really obvious wins are. They also want the moon on a stick, so you need to exercise judgement. So talk to them all the time. Listen to them. Help them understand that the thing they told you about six months ago is getting sorted, but that seemingly obvious changes in big, highly regulated industries are slow!

Build up those relationships. Then, the next time you are hiring for a new product person, encourage the superstars in those teams to apply.

It’s often a brilliant chess move.

generally younger, enthusiastic and driven people inject great energy into your teams
they bring mountains of front line experience, so they won’t fall into the trap of making things that might solve the problem
the business maximises the value it generates from the same people (a weasel-worded way of saying they cost less!)

A win for everyone.

This isn’t just theory. I’ve done it. Several times.

It works.

The most important product decision is what you don’t build

2026-09-14T00:00:00Z

There are two things I’ve tried to take a hard pass on when working on consumer-facing financial services apps.

A “document hub”.

And a “notifications centre”.

You can picture both without any help from me. To my mind they’re both examples of letting the organisation off the hook at the expense of the user. Although it’s fair to say that plenty of users have now been trained to expect these things, and to know roughly how they work — even though they’re crap.

The problem underneath is real enough. The business has legacy systems that produce PDFs — letters, statements, that sort of thing — because originally they’d have been sent out in the post. Compliance experts will also talk to you about “persistent communications channels”. So you need somewhere in the app to put all of that.

The lazy solution is a document hub. A list of files you can select and open.

Seems simple.

Except every stakeholder involved wants to do a Columbo and add just one more thing. By the end you’ve essentially rebuilt Google Drive, with tagging, archiving, printing and sharing across several channels, each with its own quirks. Not to mention clearing the security and authentication hurdles so the right person sees only the right documents. And so on, and so on.

And that is just to build the thing.

Never mind the overhead you’ve created to maintain it, month after month, year after year, as each iOS release cycle comes round and some foible you were relying on to prop up a piece of functionality gets removed unilaterally by Apple. Or Google, or Microsoft, or Amazon.

The notifications centre is the same story with a different opening line. A stakeholder asks whether we could just have a bell icon with a little red dot in the top right corner of the screen. Give it a few months and you’re building a bad Gmail clone.

#Showing people the bill

I’ve come up against both of these several times now. It is not easy to get people to let go of a mental model they’re holding in their head, particularly when a customer focus group goes some way to validating it. The cliched old Henry Ford line comes to mind — if you’d asked people what they wanted, they’d have said faster horses, not a motor car.

What I’ve found actually works is illustrating the running costs. Not the build cost. The running costs, laid out over years. That tends to bring people back from the brink.

But killing the platform doesn’t make the original problem go away. How do we communicate with our customers in a way that suits them and meets the legal obligations on our side?

The answer I’ve come back to every time is to take each use case on its own merits. Be rigorous about what actually needs to be said, and when. Then be ruthless about whether it needs a whole platform built first. It’s the same test I keep applying when picking the right problems to solve — does it make the boat go faster?

Most of the time — not always, to be fair — the answer is to use something simple, or something that already exists, even if it isn’t perfect.

Resist, resist, resist the temptation to build a one-size-fits-all.

I’ve even seen the notifications centre idea get built, and then the intent of the original message couldn’t be met by the thing that had been built to carry it.

So my advice comes in two parts. Be extremely choosy about what you let be added to your system. And be militant about taking things out.

#Nobody gets promoted for deleting things

The second part is much harder than the first, and it isn’t simply cowardice. Gerry McGovern has been saying this for a long time:

Those who create and launch are the people who are rewarded and looked up to because we still have a culture that rewards the production of things over everything else. To review, to maintain, to remove—this is all seen as lesser work.

His Top Tasks work found that stripping roughly 80 to 90 per cent of a site’s content made companies sell more, cut their support calls and helped people find what they were after faster. Removal as the improvement itself, not the tidying up afterwards. I’ve made the small-scale version of this argument before, about deleting the FAQ page.

And it runs deeper than the org chart. Klotz and colleagues, writing in Nature, ran eight experiments and found that people systematically overlook subtractive changes, even when removing was obviously the better move. Additive ideas arrive quickly and cheaply. Subtractive ones cost real cognitive effort. So we are hard wired for this.

Which means spending the brain power to work out what success genuinely is. And success is usually something out there in the world of the customer, rather than something in here, in the world of the organisation.

#But building is nearly free now, isn’t it?

DHH is thoroughly delighted about endless execution — in the age of agents, every idea, every hunch and every experiment is within immediate reach.

I think it’s easy to misunderstand that as an argument for making more stuff all the time.

Using agents to do the pruning seems like the smarter move to me. To do the maintenance. To remove things judiciously, and more carefully than anyone is going to manage by hand.

Stewart Brand’s Maintenance of Everything sits on the paradox that maintenance is absolutely necessary and also entirely optional.

Optional until it’s essential, more like.

#The elephant in the rollneck

The elephant in the room, wearing a custom-made Issey Miyake black rollneck, is of course Steve Jobs’ 1997 matrix. Two consumer products, two pro products, and one stellar product in each box.

Four boxes. One product in each. Everything else cancelled.

He then shut down all the other product lines people were working on. That pooled the engineering talent instead of spreading it thin. It was a brave move, and it did the trick.

Apple are up to something like 52 different products and services at the last count, so the end game was never to only sell four things. The point was to focus the organisation on the most important ones, so they didn’t misspend the opportunity cost that allowed them to become one of the biggest corporations in the world.

One thing at a time. Une chose à la fois.

(I’d have written a shorter post, but I couldn’t work out what to take out.)

The product strategy isn’t the roadmap

2026-09-13T00:00:00Z

Leading product decisions inside a large organisation is really, really hard. In a regulated industry, harder still.

But not for the reasons you might expect.

Here’s the part that took me a while to see. The people at the top want simplicity. They genuinely do. They preach it, and they push hundreds — sometimes thousands — of people to chase it. Remove the things we don’t need. Declutter. Think about only what’s absolutely necessary.

All laudable stuff.

And the people on the front line want precisely the same thing. The engineers, the customer service teams, the designers, the operational folk. They understand the essence of what’s required. They’ve understood it for ages.

So if the top wants simplicity and the front line wants simplicity, why is it so hard to come by?

The middle bit.

Between a leader setting a direction and something actually happening in the real world, there are layers of people whose whole job is to process that direction. There is a class of smart people working in that space whose currency is the roadmap.

I’m one of them.

#First you need a vision

To get to a roadmap, you need a vision. And the vision is the hard bit.

That’s the part where you have to be bold enough to propose something the business will actually get behind. But not so outlandish that you end up on the rocks. There’s a narrow channel between those two and most of the skill is in finding it.

Roadmaps are also a dangerous thing to own.

Once you publish one, people quite reasonably want dates against it. And that is reasonable. Building and keeping teams burns through serious £££s, so the people paying want to know what they’re getting and when they can cash the cheque.

The trouble is that putting dates against things involves predicting the future. Which, however much we all agree to pretend otherwise, is impossible. (Basecamp are blunter about this than most.)

#A strategy is a response to a challenge

Here’s what I think gets missed.

A strategy doesn’t appear out of thin air. At its core, it is a response to a challenge.

The challenge might be, “we’ve got decent market share but we’re not profitable enough”. Or it might be, “we’ve got a product people love but not enough of them use it often enough”. Those are completely different problems, and the strategy in response to each will be completely different too.

But whatever strategy you set, that is the thing that shakes out the roadmap. Not the other way round.

I’ve written before about picking the right problems to solve, and about checking each one against the strategy before you go anywhere near it. What that post quietly assumed was that a strategy existed to be checked against.

Take the first one. Not profitable enough. We can’t move on price, so we need to be more cost efficient. Which means we need to simplify, and prune the waste out of how we work.

Fine. Now go and get a few thousand people to rally round that idea as it lands on their particular team, in their particular department, with their particular targets.

A tough call.

#Then there’s the lag

The other dimension in a large organisation is the lag between strategy and execution.

You see it most clearly in the teams out on the outer reaches of the business. By the time an idea makes its way out to the provinces, the central direction has changed, or evolved, or been watered down enough that those teams can’t see any benefit in it. So they let the wave wash over them and carry on doing what they’ve always done.

And honestly? Who could blame them.

Because the question they’re asking is a fair one: how many strategic pillars, pivots, refreshes, business themes and key mandates have come and gone, and been abandoned
to short-sightedly hit the scorecard, as the organisation watches Q4 hove into view?

Quite a few, is the answer.

#Make your vision easy to use

So the real question for product leadership isn’t “what’s the strategy?”. It’s this:

How do I make my vision easy to use?

That’s an idea I’ve nicked from Luke Wroblewski, who writes about design principles needing to be specific enough that people can actually choose between options with them. “Make it easy to use” is a uselessly broad design principle. It is a surprisingly good test for a strategy.

Because humans go for the path of least resistance. All of them.

That goes for the teams producing the work. It goes for your peers, who have their own ideas that happen to depend on yours. And it goes for the leaders who need confidence that the business knows where it’s going.

So the roadmap needs to be easy to find. Easy to read. Easy to understand. And it needs to give whoever reads it some benefit that’s relevant to them, rather than to you.

Better still is a roadmap that draws automatically from the tools the business already uses, so it acts as a mirror — showing back what teams are really planning to do, rather than what everyone agreed to say they’d do.

And if you don’t like what you see in the mirror, well. At least now you can do something about it.

None of this is an argument for abolishing the roadmap. I’d be out of a job. It’s an argument for remembering which one is the tail and which one is the dog.

A List Apart Again

2025-04-27T00:00:00Z

I’ve had another article published on A List Apart. This time, I am writing about how to build products that stick.

A List Apart is the OG webzine from the people who literally wrote the book on Designing with Web Standards, Responsive Web Design, Mobile First Design, and many, many more.

Midnight Train to Georgia

2025-03-08T00:00:00Z

Inspired by Zach Waugh and his simple sketching app, Whirl, I’ve released an iOS app today that does one thing, and hopefully does it well.

It is called Milngavie Train and it shows live departure information for the next train to leave Milngavie Station in Scotland.

Why bother, you may ask! The answer is simple: when I am taking a train into town soon, the time when the next train will leave is all I need to know. I don’t need access to the entire timetabling information for the whole Scotrail network. I don’t need to use Google Maps or Apple Maps to summon the culmination of all of humanity’s geographical knowledge. But most of all, I am usually slightly late and am walking briskly down the street towards the station and I just want confirmation of two things: the train is on time AND which platform I need to aim for. (I may or may not have ended up jumping on the wrong train in the past when under time pressure. I couldn't possibly comment!)

Having to open Apple Maps, enter my starting point, my target destination and choose my mode of transport is, for me, not possible to do with my fat thumbs while walking along the street as fast as I can, and trying to cross safely through traffic. I just need one button to mash to see my answer.

So this works for me and it solves my problem. Since putting it together and testing it myself, I’ve used it loads of times.

The original target market is 1 person (me!) but when I had a look at the published passenger numbers for Milngavie Station, there are 736,148 entries and exits each year. Let’s assume that half of those people are entering the station to catch a train, so there are potentially 368,074 other people who might find it helpful. That seems like enough people for me to stick in on the iOS app store and see if anyone else thinks so.

Picking the right problems to solve

2025-03-05T00:00:00Z

You have backlog full of ideas. You probably have some work that is half-done but always seems to get stuck. There's maybe a fresh incident that's emerging. And there's a key metric that looks like it is going South but you're not even able to make time to think about it.

Sound familiar?

So how to do you get your head up and decide where to focus your attention and your team's energy?

Get methodical.

Plot these things on the urgent v important axes—the Eisenhower matrix.

Then take each one in turn and try to capture the problem statement as a simple sentence. The shorter the better.

Pick the most important+urgent problem from your matrix and compare it against your company/team/personal strategy. Is this even something that you want to solve? If it doesn't align to your strategy — i.e. it doesn't “make the boat go faster” — then stop there and ignore it.

If it does feel like the right thing to do, then you need to somehow get a sense of the benefits of solving that problem and understand the scale of the issue.

Write a list of the important questions you want to solve BEFORE looking at your data. Then go looking for the answers. Rough figures are okay. Assumptions are okay to fill in the gaps. You're just trying to understand the order of magnitude of the problem. Remember data can only tell you what's happened in the past. You’re not looking for data on its own. You are looking for signals in the data that tell you if something in the real world is happening, or not happening.

If you've come this far, you are in a good place. You have a snappy problem statement, you have a sense of the scale of the problem, and that should point to what the benefits of solving that problem might be.

Refer back to your urgent vs important matrix but this time shuffle the order of importance based on the benefits you’ve sketched. And if you have any real-world deadlines or dates that you need to consider, shuffle the urgency based on those dates.

What is sitting on the top right? It’s your #1 priority, that’s what!

Product Management 101

2024-03-05T00:00:00Z

#Outcomes not outputs

Focus on the benefits for the users and customers. It should be about outcomes not outputs.

That’s easy to say, but what does it mean?

It means...

no one cares how many meetings you went to
no one cares how many defects the regression testing pack found
no one cares how many questions your drafted for customer research sessions

It means...

be clear on why this is important for you and more importantly why it is important for the customer
look at the current situation and work out what needs to be better, more, worse, or less
think about how you could change it. What’s your theory??

It means...

work out how you would know if your theory is right?
don't “obsess about data”, obsess about the signals that tell you if your theory is good or bad
learn what you can and then apply your new knowledge to the problem. If you suspect there is more juice in the lemon, keep squeezing. Or if there isn’t, look for another one.

(Another problem, that is, not another lemon.)

The Auditors Are In

2023-02-17T00:00:00Z

Recently, I have been considering moving to a new role at work that is 100% focussed on accessibility. This led me to having a look at my own site and running the Google Lighthouse audit to check I was practising what I preach.

When I first published this website, I was very pleased that I was clocking 100/100 across the board. But... entropy. Which meant that without anything consciously being changed by me, the scores for this site had dropped.

Performance had dropped due to my use of another font for headings which was blocking the first contentful paint. I was pleased to sort that by using the preload tips in this article: https://simonhearne.com/2021/layout-shifts-webfonts/

And my introduction of a search form was a bit slapdash. I forgot to use a label on the search input which is a basic accessibility mistake. Somewhere on the way, I had used some text that wasn’t high enough contrast with the background too. Both of which were simple fixes.

Pleased to report that the scores are back up to 100! https://twitter.com/liamjnugent/status/1626636214139748366

Happy birthday, Jeffrey

2023-01-12T00:00:00Z

This might be rich coming from a person you’ve never met in person. Or, more accurately, I should say nearly met in person.

In the autumn of 2018, I travelled all the way from Scotland to Chicago to hear you talk at An Event Apart. I made the journey with my former colleague, Laurence “Fuzzy Logic” Hughes. He tuned me into web standards and the whole “A ~thing~ Apart” universe. He was the one who said we should do it. I’m very glad that we did.

Looking back today, I suppose that none of us realised that we were in the autumn of An Event Apart.

We arrived in the windy city a couple of days early so we could see the place. We trawled record store bins. We set sail on the boat tour. We had dinner in the Chicago Athletic Association and imagined meeting characters from a John Hughes movie.

I even took myself off to watch a random high school football game (Go UCW Warriors!) and found myself sitting next to the school principal who sent me a package of team T-shirts when I got home. I’m wearing one of them today.

We spent the night before the conference in a dive bar out towards Wicker Park. We drank too much beer and danced like no–one was watching. Because no–one was watching. It was empty apart from us, the barman and a handful of regulars who gave the guys with the funny accents a wide berth. “So you guys are Irish, right?”

We made our way back to the hotel, probably later than we should, and got ready for the main event. We woke up on the Monday morning and made our way to the conference venue and couldn’t wait to drink it all in.

First up: the Great Jeffrey Zeldman talking about the The Content Performance Quotient. Or so I’m told. I spent most of the talk nipping outside to take the riverside air.

Having pulled myself together, I saw you milling around in the lobby between talks. I thought that this is my chance to say hello. But I bottled it.

I wish I had had the courage.

I guess I assumed that there would be another An Event Apart in the future. By which time I would be a bit cooler, a bit more credible and perhaps there was a chance I could be a speaker myself. So you’d maybe know a bit about me and it would be easier to break the ice.

It is sad, for me, that that chance is gone. The whole scene around the An Event Part events was, or I should say is, more than the sum of its parts. I feel like it will live on through the young(er) team like Jen Simmons, Brad Frost, Dave Rupert, Mina Markham and the others, but maybe I’m too romantic about it.

Jumping back to Chicago 2018, the event itself was amazing. I learned loads. I found my tribe. Heck, this was a conference that played songs from Weasels Ripped My Flesh between talks!

So thank you, Jeffrey, for the part you played in putting it all together. And Happy Birthday from a guy you’ve nearly met.

Search done simply

2022-10-23T00:00:00Z

#The goal

To add a search function to this website as simply as possible. And to keep it in line with my ascetic ideals.

#Research and execution!

After a bit of judicious Googling on the subject of how to build a search function on a static site, I found an article by Raymond Camden called Adding Search to your Eleventy Static Site with Lunr.

His post talks about the wider discussion on how to create ‘dynamic’ features in a ‘static’ world. Remember, this website isn’t connected to a database. I can’t dynmically query the content within a database and return a set of results. In very broad strokes, I would have to create an index of all the posts at build time and then run a search query against that index.

That opens the question of forcing the user to download the entire index in order to run the query. It seems wasteful to force every user of every page to download an index of all the content in the background just in case they need it for a search query.

All of this would, of course, require some interactivity on the screen and therefore some JavaScript. For regualar readers, you will know that I have a bigger plan to avoid client-side JavaScript for as long as possible.

As I get older, I’m less militant about this idea and I am warming to the possibilty of using some as a progressive enhancement. Perhaps search is the prime candidate to be enhanced.

This was all starting to feel like a bit of a dead end.

However, one sentence jumped out at me:

For my blog here, I make use of Google’s Custom Search Engine feature. This basically lets me offload search to Google, who I hear knows a few things about search.

The germ of an idea formed whereby I could maybe capture a search query on my site but use Google to get the results for me. The trade-off would be sending a user to a Google search results screen. Given that most of the searches will probably be done by me looking for my own content, I could live with that!

Sending a search query to Google

It was back to basics here. I know from observing the URL when I do a Google search that the URL follows the pattern https://www.google.com/search?q=query+goes+here.

If I want to limit the scope of a search to a particular website, I can use a search operator to do that. I can punch in site:liamnugent.me in the search box and then add my query after that and hit submit. Google will return matching search results only from within the website https://liamnugent.me.

Looking up at the URL will show me something in the pattern https://www.google.co.uk/search?q=site%3Aliamnugent.me&q=query+goes+here.

I can use an HTML form to capture form data to fashion a URL in my desired pattern and submit that URL to Google.

Building the form

The root of the URL is: https://www.google.co.uk/search which will be the action attribute of the form.

I can use the GET method to append the form data with a ? separator.

The data I want to append is:

q=site:liamnugent.me << this will be fixed and the user doesn’t need to see this so I’ll use a hidden form input
q=query+goes+here << this will be whatever query the user submits

Here’s my code for the form:

  <form action="https://www.google.co.uk/search" method="get">
    <input type="hidden" name="q" value="site:liamnugent.me"> 
      <fieldset>      
        <input type="text" name="q">
        <input type="submit" value="Search this site">
      </fieldset>
  </form>

Bear in mind that the form will build a valid URL before submitting it to Google.

#Summing up

This works well for me just now. As I mentioned above, this is a candidate that is ripe for progressive enhancement. Although, I’m going to wait to see how often I use the search before I make any moves.

#References

https://developer.mozilla.org/en-US/docs/Learn/Forms/Sending_and_retrieving_form_data
https://ethanmarcotte.com/ – uses something similar but uses DuckDuckGo search engine rather than Google.
https://fuzzylogic.me/ – my brilliant old pal, who does something similar as the foundation for a progressively enhanced experience, but he layers on a super-nice automatic search after you type 3 characters... I may well be tapping him up for some knowledge if I decide I need to improve my search.