I think there's a dual problem here.

First, a developer putting themselves in the place of a user still may not be able to see all of the issues with their product because they are (not sure how to put this better) "too close to the work". It relates to something we talk about here on HN every now and then, namely that "technical people" often miss things that are hard for others because they just can't fathom that x thing that's easy for me could be hard for someone.

Second, I think that, in a lot of places, management makes it super hard for developers to get any data on problems other than general, abstract numbers with zero specifics included. I seems quite unreasonable to expect a developer who is being stonewalled on data or access to users by another business area to work with "our overall churn rate is x%, fix it" and actually figure out what's wrong and what needs improving.

It's the right attitude in spirit. But like how am I supposed to know how to decrease no-show rates at a clinic? How can I figure out how to increase harvest yields from autonomous tractors? Convert more enterprise sales accounts?

I know that the answer is: spend lots of time talking to customers, doing research, empathizing, etc. But then who is going to write the code while I'm doing all of that? It needs to get done, but I'm not sure why that is the job of the "development team".

One thing with OKRs is that the key results are supposed to be in your control and responsibility. You don't have control over the no-show rate, but someone has responsibility to improve that as part of their own role. If that has made it to your team, then something is probably broken. Most likely that no-show rate is part of an OKR for clinic managers or someone else. They'll come up with ideas (or consult with you for ideas) and your team is responsible for implementing the improvement or running experiments to see if it actually achieves the desired improvement.

That means your OKR will have to do with responsiveness to your customer or addressing the things your customer believes are associated with the poor no-show rate. Is your "patient reminder" system broken and failing to contact patients? Do you lack such a system? That's something you can address and control, so the OKR will have to do with that (server uptime, quality of service, features of the service, timeliness of changes to the service).

But you can potentially help the no show rate.

- Send an email to the person 2 days before their appointment

- Text them the morning of their appointment

- Build something into the CRM of the front desk that reminds them to call people the day before an appointment

- send a pre-generated google directions result to the patient N minutes before the appointment

I could go on for hours here. The job of a developer, at least in the startup world, is to understand the objective of their team and contribute to figuring out ways to reach their objective. It is not just to code up tickets that are put in front of them.

Interesting that this often doesn’t go both ways, in startup culture. I mean in terms of the non technical team members picking up enough technical skill to better understand the technical side.

I guess?

But I, as an engineer, don't know accounting, or how to setup a healthcare plan, or the intricacies of VC funding documents, etc. Thinking about how people use what you are building and how to make it better seems like table stakes for engineers in the startup world.

Thinking about the product and users is the job of engineers. So is coding a solution. And so is not coding a solution when there is a better option.

I guess if you get to a later stage startup, where you are working on very specific technical problems, you might be forgiven if you don't know what it means to the larger organization, but I can't imagine working in that environment and being happy. A fancy algorithm is cool I guess, but if I don't know how it's moving the business forward it's basically meaningless to me.

YMMV

Those are system requirements and are not what you do with OKRs.

Are they?

I would imagine the Objective is something like "Maximize the number of people we can help at our clinic". And a key result would be "The number of no-shows for appointments is below 5%".

It then follows that the product development teams (product and engineers) would get together and say something like "Great, we can think up 14 projects that might help us reduce the number of no shows. Here they are in order of easiest and/or highest likelihood to succeed to hardest and/or least likely to succeed".

How else would you use OKRs?

You build a mental model of the domain that guides the code you write. Often it amounts to "what would I want in that user's position?" aka the golden rule. As uninformed as that model may be it's better than none, and a place to start iterating on the model. In design it's usually better to be wrong than vague or random. And every line of code you write embeds a freight load of design choices, often as durable as concrete.

"Most design decisions you make as a developer affect the value users get from your product, and therefore the churn rate."

Yes but probably not in a way that matters.

Churn will be decided by a few small, hopefully well targeted issues (including price and switching cost) and so it's really Product Marketing/Managements job. The Eng. should be to meet the expectations of Product.