Recent thoughts

A New, Sketchy Horizon

Earlier this year, in February, I launched a website called Craft & Systems. I moved some of my writing there and started publishing pieces about design leadership, building teams, and the work I was doing at my jobby job.

Writing helps me think. At the time, we were building the foundation for the design function, and writing gave me somewhere to work through that. As the team has matured, I’ve been able to step back a little. I’m still in a design leadership role, but writing about leadership hasn’t been what’s driving me creatively lately.

Somewhere along the way, more of my free time started going into making things. I’d been experimenting with AI coding tools, and they were getting good enough that I could take an idea much further than I’d been able to before. An interaction I wanted to try could become something running on my phone. Then I could use it, find out what felt wrong, and change it.

That became very absorbing.

Leading teams has put some distance between me and the details of making something. Building my own apps brings me back into those details, including the ones that only show up after you’ve lived with a decision for a while. An interaction that seemed clever becomes annoying. A component that worked in one place needs to work in six. Something looks finished until you try it with your own data.

It’s been useful for my work, too. Maintaining a design system across my own products gives me practical experience to bring back to our design system team. Working with tools like Claude Code also helps me contribute to the conversations our product designers are having as they explore new ways of working. It keeps a part of my design practice active that I’ve missed.

My first app was Vael, a journaling app. I spent about three months getting it ready for the App Store. That meant working through the whole product ecosystem, from onboarding and clean, intuitive settings to the website. I lost plenty of sleep designing the core experience, but I also worked through all the less exciting details needed to get it into someone else’s hands.

It was my first real experience with a modern development workflow since using CVS and Subversion some twenty years ago. I’m now comfortable with Git, GitHub issues, automated builds, and releases. At lunch one day, some developers at work introduced me to spec-driven development. Seeing how engineers use agentic coding tools was a major level-up for me. There was always something new to figure out. I loved that.

Then I launched Vael in the App Store. I fixed bugs and added features. But I barely talked about it, didn’t market it, and eventually stopped using it myself. It turns out I’m not much of a journaler…

I liked the idea of Vael, and I loved building it. Once it existed, though, it didn’t have much of a place in my day. That was a useful thing to learn, even if it took a few months of work to get there. So I turned my attention to something I use every day but have never been entirely happy with: todo lists.

I’ve been a productivity geek since high school. How many teenagers did you know in the late nineties who carried a Palm Pilot? Well, an orange Handspring Visor, actually. Once I started working full-time, I discovered things like Inbox Zero and Kinkless GTD. I’ve paid for every version of OmniFocus since the first one. Despite that investment, I’ve also spent an unreasonable amount of money trying other task managers. Remember The Milk, Tasks Pro, Things, Todoist, TickTick, Wunderlist. I’ve given a lot of them a good go.

The habit that stuck most came from an Asian Efficiency workflow for OmniFocus: review your list each morning, flag what you intend to do, then spend the day in a Today view showing those tasks alongside anything due or overdue. That suited me. I could keep track of everything without having to look at everything all day. I also appreciated a regular review, particularly the part where you admit you’re never going to do something and delete it. But even with a setup I liked, I kept wanting a simpler experience. Less structure to maintain. Fewer decisions about where something belonged. After years of trying other people’s tools, I had a fairly good sense of what I wanted to try building.

That’s where my design studio, Sketchy Horizon, comes in. It’s a home for the apps I’m making, starting with tools I want to use myself. The first is Float, a to-do app for iPhone and Mac.

Float is built around one list. You float the things you want to keep in view and let the rest wait until you need them. There are no projects or folders. You can surface something to the top or sink it to the bottom as its importance changes. Every so often, a feature called Low Tide prompts you to review things you haven’t looked at in a while. A little help keeping the list from becoming a collection of abandoned intentions. You can turn that off, too.

I’ve been using Float every day for the last few months. That already feels like an important difference from my first app. I’ve tried to make it feel simple and a little fun, too. Something I enjoy opening and keeping beside me while I work.

I’ve been exploring notes for similar reasons. Logseq showed me how useful a daily note could be: somewhere to write without first creating a document, naming it, and deciding where it belonged. More recently, Agenda has made me appreciate having notes connected to my calendar and meetings. Those experiences are finding their way into others apps I’m working on (there’s more to figure out there, but I’m using early builds daily as well). Using these things gives me a reason to keep working on them after the initial excitement wears off.

A couple of lessons from this year are shaping what I do next.

Craft & Systems taught me that I loved creating a publication with its own name, look, and feel. I’m an old man who still finds that idea appealing. But it also meant another website to maintain, an audience to build, and a newsletter to grow. I wanted somewhere to write, but I hadn’t really wanted another undertaking around the writing. So I’ve brought those posts back here.

Vael taught me to start with something I already use and build a version that works better for me. That gives me a reason to keep using and improving it after the fun of building it wears off.

It also gave me firsthand experience of something I already knew in principle: putting an app in the App Store doesn’t do much on its own. With Float, I want to give finding those first users, hearing what they think, and talking about the product some of the care I’ve given to building it. That comes less naturally to me. I’d usually rather open the project and make something.

Heading into 2027, I have a clearer sense of where I want to spend my personal time and energy. I’ll keep writing here about design, leadership, and whatever else I’m thinking about. Sketchy Horizon gives the apps and other creative work a home of their own.

I don’t know yet what will come of them. For now, I’m enjoying having things of my own to make, use, and care about. And when I sit down to write, I have something new to draw from.

Why Shipping Faster Quietly Degrades Product Experience

Every few years, companies rediscover the same idea:

“Let’s bring product and design closer together.”

Sometimes that means tighter collaboration, which is good! Sometimes it means collapsing design into product management, which in my experience has always been… less good.

On paper, it sounds efficient, with fewer reporting lines which should lead to faster decisions and make sure everyone aligned, right? In practice, it often means one perspective quietly wins, and the product is worse for it.

The mistake is treating this tension as inefficiency. It isn’t. It’s a safeguard, and when you remove it, the product degrades in ways that are hard to see at first, but compound over time.

The industry keeps trying to remove tension between shipping and experience, but that tension is not a problem to solve—it’s a system that I think is worth nurturing.

Two lenses, same product, different incentives

Product management and product experience look at the same product and optimize for different outcomes.

Product Management optimizes For:

  • Market viability and revenue
  • Roadmap throughput and commitments
  • “Is it good enough to sell?”

Product Experience optimizes For:

  • Time-to-value and usability
  • System coherence across the product
  • “Are we quietly introducing friction?”

Same product. Different optimization functions. Different outcomes.

I spent enough years in my career as a product manager to know that, often, I was quietly eroding the quality of our product when…

  • a competitor shipped something and we felt urgency to respond;
  • sales was asking for roadmap commitments to close a deal; or
  • leadership wanted a narrative about something off strategy.

I’d look at an idea or a feature and think “Is this great? No. Is it good enough to ship? Sure.” and I’d ship it.

In contrast, when I worked as a UX lead, recommendations grounded in research and consistency were regularly deprioritized or watered down because they didn’t fit the immediate plan. Not because they were wrong, but because the system rewarded shipping over quality.

What happens when you collapse the two?

When designers report into product management, something subtle happens: the incentives align. That sounds good until you realize what you’ve removed. You’ve taken the only group explicitly thinking about usability, cohesion, and long-term clarity, and put them under the same pressure to ship and drive revenue.

Guess what starts to slip? Not catastrophically, but incrementally, and it’s hard to catch…

  • Interaction patterns start to diverge
  • The same concept gets named differently across flows
  • Onboarding quietly accumulates friction
  • Documentation lags behind reality

Individually, each decision is defensible. Collectively, the product gets harder to use.

Cohesion is one of those things everyone agrees is important but nobody is explicitly measured on. It doesn’t map cleanly to a feature, it doesn’t have a neat revenue line, and you can’t easily slot “it” into a sprint.

For example, two teams might solve the same problem differently, both reasonably, but now users have to relearn the product each time. The result is a product that works, but feels inconsistent, like it was assembled, not designed.

A centralized product experience function at least gives cohesion a fighting chance because someone is actually accountable for the overall product experience, not in theory, but in practice.

You don’t have to choose between being embedded with product teams and being a distinct function. The best setups do both. Designers and writers should be embedded in squads. They need to be in the room and shape decisions as they happen, but they should also need part of a broader product experience organization that maintains standards, systems, and a shared bar (and directly supports their personal growth as craftspersons). Remove the second part and teams drift. Remove the first and you get ivory tower design.

Plenty of successful companies lean heavily product-led with embedded design. Amazon is often referenced for having strong product ownership, fast iteration, and an experience that can feel… uneven, depending on where you are. Apple is the canonical case for prioritizing design coherence at the highest level with strong, centralized control over the experience. Slower in some respects, but extremely cohesive.

Then there’s a middle ground.

Companies like Stripe and Airbnb invest heavily in design systems, content, and experience quality while still maintaining strong product management discipline. Companies who define their markets with product-led, best-in-class user experiences don’t pretend the tension doesn’t exist, they operationalize it.

You can argue causation, but you can’t ignore the patterns:

  • If product management dominates completely, you tend to get a product that grows in capability and declines in usability.
  • If product experience over-rotates without enough connection to market reality, you risk building something elegant that doesn’t actually matter.

Neither failure mode is rare.

So how does Product Experience actually drive outcomes?

This is the part that usually gets hand-waved. If product management owns the roadmap, how can product experience be accountable for anything real? If you don’t have product managers reporting to you, aren’t you just influencing from the sidelines again? It depends on how you operate.

Product experience doesn’t need to own the roadmap to shape it, but it needs leverage in a few specific places:

1. Paying for experience up front

This is the most important part, and the part that most teams avoid: if experience improvements are funded with whatever time is “left over,” they won’t happen.

There is never any leftover time, so product management and product experience need an explicit agreement.

A portion of every roadmap must reserved for improving the product itself. Not new features. Not net-new capability. Improving clarity. Reducing friction. Fixing inconsistencies. Paying down experience debt.

Let’s say 10%, maybe 20% if you really care. The exact number matters less than overall the commitment. It’s the same logic as saving for retirement—if you wait until the end of the month to see what’s left, you won’t save anything. If you take it off the top, it compounds.

Experience works the same way. Small, consistent investments in usability, cohesion, and clarity compound into a product that is easier to adopt, easier to expand, and harder to churn from.

Importantly, this investment needs to be visible to the business. If you’re reserving part of the roadmap for improving the experience, you need to know if it’s working. You have to answer the business’s ultimate question: Are we getting our money’s worth?

You prove it by translating product friction into business costs:

  • Time to value isn’t just a usability metric; it’s what drives shorter sales cycles and faster enterprise deployments.
  • Task success and drop-off aren’t just funnel metrics; they are the strong indicators of Net Revenue Retention (NRR) and churn.
  • Support load isn’t just about frustrated users; it’s a direct operational cost eating into your margins.

Track these metrics not as a dashboard for its own sake, but as feedback on whether your investments in product experience are actually protecting revenue and reducing operational drag. Otherwise, experience work becomes indistinguishable from preference, and it’s easy to cut the next time priorities shift.

2. Defining and enforcing quality at the system level

If usability, clarity, and cohesion are treated as “nice to have,” they will lose every time. If they’re not part of the definition of done, they’re optional, and optional work doesn’t survive roadmap pressure.

Product experience has to set non-negotiable standards. Interaction patterns, content models, accessibility, and system behaviours.

But standards alone don’t hold. They need to be encoded into systems. Design systems. Content systems. Interaction principles. These aren’t just libraries, they’re control surfaces. When they are well-run, they quietly shape every roadmap decision.

A product team can choose what to build, but how it fits into the system is constrained by these layers. That’s real leverage.

Product Experience shouldn’t ask for permission to improve things, they need to define what acceptable looks like, and build that into how the product gets made.

3. Being there early, with a way to push back

If product experience shows up at the end to “polish,” it has already lost. The leverage is upstream: framing problems and shaping solutions early.

This is why embedded teams matter. You’re in the room when decisions are still fluid, not after they’ve hardened.

But being in the room isn’t enough. There will be disagreements, and there should be disagreements as part of a healthy tension. If product experience is only present but not empowered, it becomes advisory again, and “advisory” doesn’t win when timelines get tight.

There needs to be a clear path to push back when something materially impacts the experience. Not for every pixel, but for the decisions that compound.

If everything rolls up to product, those disagreements resolve in one direction. If product experience has its own leadership and escalation path, those trade-offs stay visible.

That’s what keeps experience from getting negotiated away, one “reasonable” decision at a time.

If everyone owns it, no one does

Product management decides what to build and when.

Product experience shapes how it comes together and whether it actually works as a system.

If both are functioning well, neither is optional. Instead of arguing about reporting lines, it’s worth asking something more concrete: Who is actually accountable for the experience of the product?

If “everyone” owns product experience, no one is actually accountable for it.

This isn’t about intent. Product managers aren’t ignoring experience, they’re doing their job. Designers and writers aren’t obsessing over craft for fun, they’re trying to prevent problems that compound quietly over time.

This is about incentives. Structure decides what wins when things get tight.

If your system doesn’t protect both perspectives, one will fade. Not all at once, but gradually. You won’t feel it internally, but your users will.

Photo by Vlado Paunovic on Unsplash

Introducing Craft & Systems

At the end of 2024, I did something I had not done in 25 years: I started blogging again. The last time I wrote consistently online was around the turn of the millennium. Back then it was pure experimentation (and mostly teen angst, honestly). A personal site, some thoughts, some code, and a lot of curiosity. Then life and career took over.

Fast forward to late 2024 and I was working at a web hosting company. We were building tools for people who publish on the web, and it felt wrong not to be using the product myself—if you build for creators, you should create. So I spun up this WordPress site you’re reading now.

My goal was more pragmatic than passionate: reacquaint myself with WordPress, understand user experience, and live in the product. WordPress has changed little at its core over the years. Posts, pages, and themes still work much the same way they did when I was building client sites in the mid-aughts. The muscle memory came back quickly.

Within a weekend I had the basics in place, and I even had an old design ready to go. The HTML and CSS had been sitting in a folder on my NAS since 2005! I was surprised at how well it held up. A layout I had coded years ago and never shipped worked in modern browsers with minimal adjustment. The site was essentially done, so I wired it up, tweaked a few things, and published my first post.

From there I set a simple target: one post per month. It felt sustainable and frequent enough to create a signal, yet infrequent enough to fit into my life. I did not want noise. I wanted intention.

Over the course of the year something interesting happened: my writing began to converge around a theme. The posts that felt most natural were about design, product management, and leadership. They were grounded in experience, not theory. I found myself clarifying what I believe about craft, systems, teams, and decision making.

I also wrote personal pieces. A few pet peeves. Observations that had nothing to do with design. They were fun, but they diluted the signal.

That tension led to a decision.

Today I am launching a new blog: Craft & Systems. It is where I will publish more regularly about design and software leadership. Focused and opinionated, but grounded in practice. I have migrated my design and product leadership posts there so they can live together as a coherent body of work. If that is the kind of writing you come here for, take a look and consider subscribing to my newsletter.

Publishing here will likely be more sporadic as I put more energy into Craft & Systems, but it will not disappear. This space will remain my personal outlet for the desk gadget posts, the occasional rant, all the things that do not quite fit into a professional throughline, but I still want to write about.

In some ways, this feels like a return to 1999. A personal corner of the web that is mine. Just more intentional about where different ideas belong.

Thanks for reading then, and now.

Read more thoughts…