Gary Murray – Product Lead

  • Stop building museum pieces

    There’s a pattern I keep seeing in product teams: we aim for the “right” version of something, and in doing so, we never actually ship the useful version.

    Nobody wakes up intending to slow things down. It happens gradually:

    • We add one more abstraction “because we’ll need it later,”
    • We align the design system,
    • We make it extensible from day one,
    • We wait for the other team to catch up, and
    • Suddenly the customer has… nothing.

    So this is a post about resisting that pull and a few principles you can use when you feel the work drifting away from real users.

    1. Perfect is usually optimized for us, not for customers

    When teams say “let’s do it properly,” they’re almost always talking about internal satisfaction: elegant code, unified UI, one way of doing things, future-proofing.

    Customers do not care.

    Customers care about:

    • Can I do the thing?
    • Are the numbers right?
    • Is it faster than the way I do it today?

    If the answer to those three is “not yet, we’re still designing the framework,” that’s a smell. That’s when “perfect” has won on the inside and “useful” has lost on the outside.

    Principle: if the work looks impressive in a demo to your colleagues but invisible to a customer, you’re optimizing the wrong audience.

    1. Momentum > completeness

    A lot of products get stuck because they try to do two hard things at once:

    • Replace or clean up the old way, and
    • Introduce a better, new way.

    Doing both simultaneously sounds responsible, but in practice it doubles the surface area, doubles decisions, and makes it harder to declare anything “done.”

    It’s almost always better to pick one axis:

    • either: “We’re cleaning up what exists, no new scope.”
    • or: “We’re adding net-new value, we’ll redo the old thing later.”

    Trying to do both is how you end up with PM notes like “blocked on design direction” for weeks.

    Principle: reduce simultaneity. Ship on one dimension at a time.

    1. The hidden tax of “doing it right”

    “Let’s do it right” sounds mature, but it has a hidden cost:

    • It introduces new dependencies (on platform, on design systems, on other teams),
    • It raises the minimum viable release to something non-minimal,
    • It makes it harder to test with real users because nothing is small anymore.
    • What people call “right” is often just “more coordinated.”

    Coordination is good. But coordination is not value.

    Principle: don’t let “future-proof” outvote “presently useful.”

    1. Ship the observable thing first

    You can’t learn from a Figma file. You can’t learn from an architecture diagram. You can only learn from something a real person used, even briefly.

    So a good forcing question is:

    “What is the smallest version of this work that a real user can see and tell us something about?”

    It’s not:

    • “What’s the smallest version that makes the system elegant”, or
    • “What’s the smallest version that supports every extension”, or
    • “What’s the smallest version that marketing can make a full launch page for.”

    Just: can someone use it and react?

    Principle: if you can’t put it in front of 3 users this week, it’s too big.

    1. Defer platformization

    Teams love to build for “everyone who might use this later.” That’s how you end up with general-purpose, no-purpose features.

    There’s a better order:

    • Build the thing for you (your current use case),
    • Let it prove itself,
    • Then harden it for others.

    This feels backwards to some people and you may hear some shouting: “We’ll have to refactor!” But, refactoring a working, used feature is always easier than resurrecting an unused, overbuilt one.

    Principle: make it useful, then make it reusable.

    1. Say what you’re not doing

    A lot of scope creep is just unspoken anxiety.

    • Design worries: “Will we have to redo this for mobile?”
    • Engineering worries: “Will this scale when we add X?”
    • Product worries: “Will partners be angry we didn’t make it extensible?”

    If you don’t name the boundaries, people will quietly build for the biggest possible future.

    So write it down, for example:

    • This version is web-first.
    • This version is for internal data only.
    • This version is not extensible.
    • This version is about visibility, not automation.
    • This version is for 1–2 key personas.

    When you do that, it becomes much easier to ship something small without everyone feeling like they failed the imaginary final state.

    Principle: constraints make shipping emotionally safe.

    1. Lead with the commercial / outcome story

    One more thing that helps: tie the smaller, shippable version to an outcome that leadership cares about.

    Examples:

    • “Shipping this thin slice unblocks real-user feedback in the same quarter.”
    • “Getting this out gives us retention / activation data we can’t get from mocks.”
    • “A narrow v1 reduces migration/support until we know merchants actually want it.”

    When there’s a clear business reason to ship small, it’s much harder for “let’s just make it perfect” to win the argument.

    Principle: small releases need a big why.

    1. How to spot you’re drifting into perfectionism

    You can almost diagnose it from meetings:

    • “Let’s wait until the component library is ready.”
    • “Let’s not show it to users until we can tell the whole story.”
    • “Let’s solve this for all products / all regions / all payment methods.”
    • “Let’s figure out the long-term IA first.”
    • “Let’s make it consistent with the future experience.”

    None of those are bad sentences. But if they appear before anyone has seen a working version, you’re in danger territory.

    Principle: if future concerns show up before present value, you’re drifting.

    1. The stance

    If I had to compress this into one stance, it’s this:

    Shipping is how we find out. Perfect is how we postpone finding out.

    You don’t discover reality by thinking harder. You discover it by putting something small, slightly embarrassing, slightly incomplete in front of the people you’re actually building for.

    If it lands, great, you’ve earned the right to make it nicer.
    If it doesn’t, great, you found out early and have not over invested.

    Either way, you’ve learned from real world feedback, from your customers who pay to use your product.

  • AI as a Consumer Advocate

    Let me preface all of this by saying I’m not a lawyer.

    I’m just someone who bought something (a fairly expensive thing at that)…and then a safety recall on a part of that product turned that shiny new purchase into something I couldn’t use a few months later.

    What followed was a maze: the seller of the product pointed one way, the manufacturer of the recalled parts another, I got different case numbers, mixed shipping instructions, and at one point there weren’t even boxes available to send the part in for inspection.

    Meanwhile, my new product was for all intents and purposes rendered unusable unless I was willing to incur additional costs to make it temporarily usable.

    The turning point in my experience wasn’t a magic phone call. It was opening ChatGPT and saying, “Here’s my issue, explain my rights like I’m five, and help me ask for the right fix if there is one.”

    The TL;DR on what I faced

    • Mixed messages between seller and manufacturer
    • Confusing “send it here / no, send it there” instructions
    • Logistics issues (even simple packaging became a blocker)
    • Weeks of waiting with an unusable product

    I didn’t want drama; I wanted a safe, working product, without incurring extra costs or having to deal with very unclear timeframes.

    How ChatGPT actually helped me

    ChatGPT helped point out that the part manufacturer in this case offered only one solution which came with significant inconvenience.

    ChatGPT helped me understand that legally this was not correct, and further to this, that legally, the seller was actually obliged to fix it free of charge, within a reasonable time, and without significant inconvenience; and when it’s a recall, consumers should have a real choice of remedies (if repair isn’t possible, that usually means replacement or refund).

    This meant that I could actually contact the seller of the product (who at this point was trying to quietly stay out of things) and ask for a solution.

    ChatGPT helped write the emails I’d probably have spent ages trying to write – keeping them short, calm and specific. It helped me:

    • Summarise my timeline
    • Ask for practical outcomes (safe replacement or refund)
    • Include logistics (collection, packaging, fitting)
    • Set a clear, short deadline

    And maybe more importantly, it kept my tone steady, even when the first response I got from the supplier was pretty patronising and had me getting even more frustrated!

    But, with ChatGPT, there were no rants. Just a consistent “Here’s the problem, here’s what the rules say, here’s what I’m asking for.”

    It also gave me a backup of an escalation map. If things stalled, I knew the next steps (consumer mediation, small-claims-style routes). Just knowing that made me more confident in my communications with both the seller and manufacturer.

    The key rights that mattered (EU-flavoured, in plain English)

    • Seller responsibility: Your contract is with the seller. They’re on the hook to make it right free of charge, as quickly as reasonably possible, and without major hassle for you—collection, packaging, and fitting included.
    • Recall remedies: In a recall, you should get a genuine choice (often replacement or refund if repair isn’t feasible). If it drags on or becomes a pain, you can push for a refund.
    • No extra costs: You shouldn’t pay to fix a safety problem with something you already bought.

    Note: this is a practical summary. It’s not legal advice.

    The playbook I used (steal this if you want!)

    1. Write a timeline. Dates, who said what, any blockers (routing mistakes, no packaging, etc.).
    2. Ask ChatGPT for a checklist of your rights tailored to your situation.
    3. Send a calm, clear email to the seller (cc the manufacturer if helpful):
      • “The product is unusable due to a safety issue.”
      • “Please provide a safe replacement or an adequate refund.”
      • “Cover the logistics and fitting.”
      • “Please confirm by [specific date].”
    4. Don’t confuse goodwill with the fix. The seller tried this, but reimbursing small costs is nice; it’s not the remedy.
    5. Follow up on your deadline with the same message—polite and persistent.
    6. Escalate if needed. Knowing you have options keeps things moving.

    How it ended

    After a few firm, well-structured exchanges, I got a free replacement within a week that solved the safety issue and made the product usable again. Not instant, but once the requests were precise and grounded in the right standards, things clicked.

    Why this matters

    Most of us don’t speak “legal.” We shouldn’t have to.

    ChatGPT didn’t argue in court; it helped me ask for the right thing, the right way, at the right time. That alone turned a frustrating recall into a manageable process, and a better outcome (for me at least).

    Prompts you can copy/paste

    “Explain my rights in the EU when a product I bought is affected by a safety recall. Keep it plain English and actionable.”

    “Draft a short, polite email to the seller asking for a remedy within a reasonable time and without significant inconvenience. Include collection/packaging/fitting and a deadline.”

    “Turn this timeline into a concise email with dates.”

    “If the manufacturer only offers replacement, when can I ask for a refund? Keep it brief.”

    “Write a firm but friendly follow-up if I don’t have tracking/ETA by [date].”

    Legal disclaimer

    This was one person’s experience (mine), and as such is not legal advice. But if you’re stuck in a similar mess, this approach may help you move from confusion to resolution—without needing a law degree.

  • If your design only works in colour, it doesn’t work

    Over the weekend, I signed up for a product that asked me to create a password:

    Said signup form…

    Simple enough, right?

    Except the form showed which rules I’d met with little red and green dots. No text, no icons, no context. Just colors.

    Guess what? If you’re one of the 300 million people worldwide with colour blindness, that signup form might as well be written in invisible ink.

    And let’s be clear: this isn’t just bad design. It’s exclusion.

    The Ugly Truth About Color-Only Design

    When you rely on colour alone, you’re silently telling 8% of men and 0.5% of women this product wasn’t built for you.

    That’s thousands of potential customers bouncing at the very first step because they can’t tell which requirement they failed. Imagine investing in ads, marketing, onboarding flows…and then losing users because you couldn’t be bothered to add an icon or a line of text.

    This isn’t just an accessibility issue. It’s a conversion killer.

    Why We Should All Care

    Accessibility isn’t niche. If your product scales, color blind users aren’t “edge cases” — they’re paying customers.

    It’s lazy design. Adding an icon or some microcopy is hardly expensive, yet it prevents real exclusion.

    We’re all one bad design choice away from alienating people who would love to use what we’ve built.

    And honestly? It’s 2025. We should know better by now.

    What Good Looks Like

    Here’s the bare minimum we owe our users:

    ✔️ Pair color with symbols (✔️ / ✖️ or clear icons)
    ✔️ Add short text (“Needs a special character”)
    ✔️ Test your work with color-blindness simulators
    ✔️ Follow WCAG – they’ve been telling us this for years

    Accessibility isn’t rocket science. It’s empathy in interface form.

    A Call-Out to Our Industry

    The next time you design a flow and reach for green = good, red = bad… STOP!

    Ask yourself:

    • What happens if someone can’t see the difference?
    • Would they still understand what to do?
    • Would they still feel welcome here?

    If the answer’s no, you’ve just built a gate that keeps people out.

    And that’s on you — not them.

    Let’s Do Better

    Every time we ignore accessibility, we exclude real people. People trying to give us their money, time, and trust.

    Design isn’t just about aesthetics. It’s about inclusion.
    And exclusion, whether intentional or not, is always bad design.

  • The Silent Grief of Remote Work

    I’ve always believed in the immense benefits of remote work—the flexibility, the freedom, the ability to connect with brilliant people from all over the world. I’ve had the privilege of working alongside colleagues from diverse backgrounds, cultures, and time zones, and these digital connections have enriched my life in ways I never expected. Remote work allows for a kind of collaboration that transcends borders, and in many ways, it’s become my ideal work environment.

    But, as with any system, there are costs that we don’t always talk about, and one of the most difficult challenges I’ve faced working remotely is the loss of colleagues due to layoffs. Recently, nearly 300 of my colleagues were let go, and the impact was profound. It wasn’t just a professional shift—it felt personal. These weren’t just coworkers; some of them were people I had built deep, meaningful relationships with, people who had become a part of my remote “family.”

    What’s unique about remote work is that our relationships are built through digital spaces. We don’t have the spontaneous, in-person moments that often create bonds in a physical office. There are no coffee breaks or impromptu chats by the water cooler. Instead, our connections form through Slack messages, video calls, and shared projects. We celebrate wins, we support each other through challenges, and we often lean on each other in ways that go beyond work.

    When those bonds are severed, the void left behind is stark. The absence of a colleague, a friend, or a mentor is felt deeply, even though the only thing we shared was a screen and a sense of purpose. It’s a loss that doesn’t fit neatly into the conversation about remote work’s advantages. There’s no physical office to return to for closure, no in-person goodbye that marks the end of a chapter. It’s just the silence that follows when someone who has been a part of your work life is no longer there.

    And yet, even with this emotional cost, I still stand firmly behind the overall benefits of remote work. The flexibility it provides, the opportunities for collaboration, and the ability to connect with incredible people all over the world far outweigh the challenges. Remote work has changed my life for the better, and I believe it’s the future of work for many.

    But this loss—the silent grief that comes with losing colleagues who were once integral to your daily rhythm—is one of the real costs that we need to acknowledge. It’s a challenge that doesn’t have an easy solution, and it’s one that I think is often overlooked in the broader conversation about remote work’s many benefits.

    When we talk about remote work, we often focus on the positives—productivity, work-life balance, global collaboration. But the emotional impact of losing people who have become family is something we don’t always address. It’s not a flaw of remote work itself, but rather a reality that comes with the territory. The relationships we build in this digital space are real, and when they are lost, it’s a grief that doesn’t fit neatly into the usual narratives.

    I believe we can continue to make remote work better, more inclusive, and more connected. But in doing so, it’s important that we don’t forget the emotional cost of these virtual connections—because in some ways, they are as real as any physical relationship, and their loss can leave a lasting impact.

  • Please Be Patient

    I recently read a daily devotional that really stuck with me. It told the story of someone pulling up behind a car at a red light and noticing a bright sticker on the rear window that said: “New Driver. Please Be Patient.”

    Simple, right? But powerful.

    The devotional went on to wonder—what if people walked around with signs like that? “New Parent.” “Grieving.” “Still Figuring It Out.” If we knew what others were going through, would we respond with more grace, more patience, more compassion?

    That reflection made me think about product management—about how often we operate at full speed, chasing deadlines and KPIs, without pausing to consider what others (or even we ourselves) might be navigating behind the scenes.

    Here’s how that one line—Please be patient—translates into building better products, better teams, and better habits of leadership.

    Be Patient with Your Users

    Not every user is an expert. They didn’t build the product. They might be stressed, confused, in a hurry, or learning something new.

    Design with that in mind. Write helpful error messages. Offer simple onboarding. Make space for second chances. Assume they’re doing their best.

    Sometimes, we treat users like they’re doing something wrong—when really, they’re just trying to figure things out. That’s your cue to show up with clarity and kindness.

    Be Patient with Your Team

    That engineer might be ramping up. That designer might be in the middle of a tough critique cycle. That marketer might be balancing multiple launches. We’re quick to notice missed deadlines—but slower to see silent struggles.

    Create a culture where “Please be patient” is more than a platitude. Normalize asking for help. Celebrate growth over speed. Make it okay to not be okay.

    If someone’s learning, support them. If someone’s overwhelmed, notice. People do better when they feel seen.

    Be Patient with Yourself

    Product management is messy. It’s storytelling, prioritization, psychology, herding cats, and playing translator between worlds. You’re not going to get it all right all the time.

    And that’s okay.

    Give yourself grace. You’re still learning. You’re still growing. Some days will feel like wins. Others will feel like survival. Keep going anyway.

    Stick your own sign on the mirror if you need to: “Still Learning. Please Be Patient.”

    Leading Like Jesus

    What struck me most about that devotional wasn’t just the sticker—it was the reminder of how Jesus moved through the world. He wasn’t rushed. He wasn’t reactive. He saw people. He stopped. He made time.

    That’s the model.

    In Ephesians 4:1–3, Paul urges us to live “a life worthy of the calling [we] have received,” and that includes being “completely humble and gentle; be patient, bearing with one another in love.”

    That’s not just good theology—it’s good leadership.

    Whether you’re shipping a feature, running a sprint, coaching a teammate, or debugging your own thoughts—remember the sticker:

    “Please be patient.”

    You never know what someone’s carrying. But you always have a choice in how you respond.