What Counts as Good Work?

For a long time, while doing research, I had a relatively clear idea of what good work looked like. I enjoyed understanding problems, comparing different approaches, and proposing new ones. There were also recognizable ways to evaluate the results: experiments, publications, citations.

When I moved toward more applied research and product development, things were less straightforward. A technically good result was not necessarily a good product outcome. That can be a bit shocking at the beginning.

You could work on something for months, get promising technical results, and still struggle to understand why they didn't translate into product value.

Was the research insufficient? Was the problem poorly scoped? Did the result create value, but not enough to matter?

For me, that uncertainty was often more frustrating than an unsuccessful result.

If I understood why something hadn't worked, I could learn from it. Without that understanding, it was difficult even to know what I should improve.

Seeing More of the System

Today, my work is quite different.

As a technical founder, I make decisions about what to build, which technical approach to use, how much effort to invest, and when something is "good enough."

Those decisions are not necessarily easier than the research problems I worked on before. And I certainly don't know whether I always make the right ones.

But I can see more of what happens afterward.

I can see whether a feature is used, whether an implementation creates difficulties, whether something helps a customer, or whether a technical investment was more expensive than expected.

These signals are imperfect. Still, I have more opportunities to connect my decisions with their consequences.

I hadn't fully appreciated how important that was to me.

It isn't only about knowing whether the company is doing well.

It's about having enough information to learn whether my own contribution was useful.

The Other Side of Feedback

More recently, I had the opportunity to guide someone working on research and engineering problems.

We spent considerable time reviewing experiments, discussing methodology, and interpreting results. But I also focused on two questions:

What did the experiment actually establish?

What did that mean for the product?

I tried to distinguish between the quality of the research and its usefulness for the product.

Those aren't the same thing.

A well-designed experiment might answer its research question convincingly without resolving the product decision.

That doesn't make the research bad. It means there is another question to answer, or perhaps that we should have asked a different question in the first place.

Looking back, I think part of my approach to feedback came from my earlier experiences. I knew how frustrating it was not to understand what my own work had accomplished, and I wanted to make that clearer for someone else.

What Counts as Good Work?

Good feedback helps you understand whether you did something well. It should also help you understand what happened because of your work.

Those are different questions.

A project might not achieve its intended outcome even when the people working on it made good decisions. And a technically impressive result might create little practical value.

Without enough feedback, these situations can be difficult to distinguish.

This matters for organizations because they need to learn which investments are worthwhile. But it also matters for individuals.

Sometimes the conclusion will be disappointing. But understanding why is what allows us to learn from it.