Two ways to build

I've been making software for a long time. That's meant seeing trends come and go, things shift, new technology emerge, and now the advent of AI.

But, I also feel like I've got so much to learn about building a great user experience, defining a product, and building something that helps people; or, as one colleague says, invests in rather than extracts from.

After all this time, I believe there's two ways to make a good product, and so many companies and teams miss this.

The first way

Build something for yourself.

I'm not talking about the ideal version of yourself, the theoretical, the optimized "what if everything went right and I'll add all these options"—-no, the actual version that will use it today. The path that you'll walk down once it's done; the ways the software benefit you in the here and now. Build that, and build it quick. As fast as you can.

So many times I've seen the concept of dogfooding, but as an ideal construct, an "if everything went right, the software would do this." Even last night I had a moment where I was considering an extra feature, but realized in practice I wouldn't be able to test that path, and so pruned it out.

When you're creating for yourself, or dogfooding as we say, make sure it matches your use case, solves your problems today, exactly as they exist. Anything beyond that is speculation and causes frustration and delays. Just get that first version immediately.

Because, and this next part is crucial. You want to be using the software as soon as possible, in real-world scenarios.

Using your stuff

I'll give you an example. I've been tinkering with a number of personal projects that attempt to improve on software that I've long used, but which don't quite work for me.

In each of those cases, I see something I want to improve, and so I've started designing my own—-hopefully better for me—-version.

There comes a moment where I have to decide if I'm going to use the software I'm replacing, or the one I've designed for myself. And if I don't get to that point, if I keep things theoretical, I won't feel the pain of dogfooding, using my own software.

But, while I'm designing, I'm not using. It's like editing and writing, you can't do both at the same time-—or at least I can't. You need to be in the creative flow, or the fixing flow. And the two paths don't cross.

So when I'm dogfooding, building something that solves my own need, it matters to get to a place where—-buggy and broken though it may be-—I can start testing it in real world examples.

All the projects I've done fallen or succeeded in this category. If I'm not using them for my use case quickly, they'll die.

When I lay out a user flow, I imagine my personal use case need, and often am directionally right—-it's for me after all—-but until I switch to the other side of my brain, and use it in a real scenario, live, and solving my need-—well, it's just not real.

For instance, I might create a form flow to submit a project. When it comes time to sit down and submit one for real, well, that's when the brain switches over and starts to see the input fields for what they are; a thing to get through toward a purpose; not a delight in and of themselves. And if they don't solve my problem, it's jarring.

That's the beauty of dogfooding, that's the beauty of getting something down as quickly as possible and trying to work through the problem in a real setting. You'll see the mistakes, they'll stand out to you, and then you'll be in the right position to fix them (quickly), without having to guess. You know what's wrong, and the answer is right in front of you.

I'll give you one quick example. I'm trying to replace TextEdit on my Mac. I love it, use it everyday; but it's got a flaw (for me). So I'm working to design an app that solves my problem. It's easy to design, get it looking just right; but until I'm trying to use it as software (like I am now), the happy path use case I imagined starts to show where it could be improved. I've found several things I need to fix, merely while editing this post in the new app I build. That's dogfooding.

Helping others

The second type of good design practice is to get as close to the user as you can, to the real person with the problem. It's harder than dogfooding, because you have to go out of your way to find people, actually talk and engage with them, and understand what they need to solve. When that happens, though, the effect is equally as powerful as the high you get from fixing your own stuff.

You're helping someone else, you're making their life easier, you're seeing the problem they want to solve through their own eyes, and are empowered to fix it.

Where they each fit

I've been thinking lately about the two use cases of designing software, and which I prefer.

Dogfooding is comfortable (I need to find a better term, sounds so gross), it's always available to me—-provided I do it the right way. It solves my problems, and helps me build software that I love.

But the other way, being near to the user, hearing their needs, helping them accomplish their problems, it's got something special. It's harder, but you come away at the end of the day knowing you made someone else's life easier.

I don't think I can really choose. I love both, and I want to get better at each in its own way.