Gary Murray – Product Lead

Product

  • Swanny – an AI-based cycling training app I built with Claude, and then stopped

    Earlier this year I spent a week exploring what was possible with Claude Code as my “engineering partner”. As someone with a design and product background I wanted to see how possible it would be for me to work with Claude to build a fully functional iOS app.

    As a keen amateur cyclist, I have lots of data across Strava, Garmin and Zwift. Over the last few years I’ve tried various training platforms like TrainingPeaks, WKO5, Intervials.icu and Xert – but I found that none of them really gave me what I was looking for. I was looking for an experience closer to that of having a personal coach – someone who would help explain all the data to me – but without the commitment and cost – because, as I said at the start, I was a keen amateur cyclist!

    So I set out with the goal of building an AI-based training coach. I called it Swanny – a “swanny” in cycling is the colloquial nickname for a soigneur. They are a non-riding support staff member who takes care of bicycle racers.

    The app pulled in your rides from Strava and Zwift, figured out what’s actually holding your fitness back, and gave you a training plan and a weekly review in plain English instead of a wall of charts. The bet I was actually testing, on myself, was: could an LLM do enough of what a $100-300/month human coach does that it’s worth it for the huge pile of amateur riders who’ll never hire one?

    I’ve ended up shelving it though. Not because the build didn’t work – it did. I used it myself for a while and even got as far as having some people sign up on a waiting list. Thanks for to those who expressed interest!

    I’m shelving it because Strava themselves rolled out MCP access to everyone’s ride data this year, and that quietly wrecked the specific bet I made.

    What it was

    Three apps, one Turborepo: a Hono API, an Expo app for iOS/Android, Postgres behind Drizzle on Neon. Clerk for auth, Stripe for payments, Resend for email, Claude Sonnet 4 doing the actual coaching bit. Rides came in through Strava OAuth, Zwift, or a raw FIT upload if neither worked.

    On top of that sat four things that the AI actually wrote:

    • A rolling 7-day training plan (cached 24 hours so I wasn’t burning tokens every time I opened the app),
    • a weekly review that’s meant to read like an email from an actual coach, and
    • a per-ride assessment that fires right after a sync, and a race plan for pacing and fuelling.

    If I’m honest, none of that list was the hard bit though. Wiring a call to Claude with a system prompt and some numbers was quick. What actually ate the most time was making it trustworthy enough that I’d take training advice from it – and I only found the places it wasn’t trustworthy because I was the user myself.

    Why I actually stopped

    I submitted the app to Strava for approval and to get the API limits lifted so I could open it up to my wait list. Days turned into weeks, weeks turned into months, and then finally I heard that Strava had decided to give every user MCP access to their own ride history.

    This meant the thing I was thinking of trying to build a business around, “connect your data, get an AI to make sense of it,” was now something anyone could get by pointing a general assistant at their own account. Swanny’s edge was never really the AI. It was the plumbing that turned messy ride data into something an LLM could reason about without hallucinating half of it. And that plumbing was what just stopped being scarce, more or less overnight.

    I don’t think it kills the whole category though – there’s real depth left in the sport-science side that a generic query won’t hand you for free: interval detection, zone modelling, periodisation, the trust guardrails above. But it kills the version I’d built, where “we plug into your data” was doing real work in the pitch.

    I could have kept building anyway. I’d already put a time into it, the app worked, and it was tempting to just keep going because it existed. Instead, I looked at what the market had just done to my actual differentiation and called it, rather than defending a plan because I’d already started it.

    What I actually took from it

    Setting aside that I got an API, a mobile app, a schema, auth, payments and four working AI features out in about a week, with Claude as my partner – the part I’d genuinely stand behind is the judgment calls sitting underneath all of it.

    Using the product myself, every day, helped me:

    • Decide where the quality bar was,
    • Decide what had to be non-negotiable, even when nobody’s asked for it yet,
    • Notice a small domain detail before it quietly poisoned everything downstream of it,
    • Understand the unit economics before getting attached to the idea.

    None of that is specific to a cycling app though. It’s what good product judgment actually looks like in practice, in my opinion, and I was able to do it at a scale small enough that I could see every part of it myself.

  • 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.

  • 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.

  • 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.

  • A Conversation Around WooCommerce Blocks

    I recently joined Bob and his hew co-host Noëlle Steegs from Do The Woo to talk about our work on the WooCommerce Blocks.

    It was a great conversation with both of them, my colleague, Darren Ethier and Manos Psychogyiopoulos, Head of Product at SomewhereWarm. We covered our current work on the new Cart and Checkout blocks for WooCommerce, how we approaching working with our third party community and the challenges we face as we look to improve the checkout experience for our merchants and their customers.

    If you want to get the latest on our work on the WooCommerce Blocks have a listen below.