Practically, having no staging is such a hard concept for people to get their heads around.
It’s one more safety net gone, but it’s a good one.
Maturity of the business, team and product play a big part in this decision.
So they can see development happening, can check or approve changes or can see if the api change they made breaks anything.
They are usually very happy about this and keeps away tons of problems in prod.
What would be the best way of approaching that without staging?
Alternatively (since you said “prior to pull request”) local builds, screen sharing, and live conversations with stakeholders.
Alternatively (if you don’t want to screen share) continuous deployment, feature flags, and a PR-free review technique such as pairing or mobbing.
Alternatively (if you don’t want pairing or mobbing) continuous deployment, feature flags, robust automated tests, and post-deployment code review.
Edit: Parent comment has been edited, originally it was just "Feature flags tied to user accounts." To address the rest: screen recording is sadly not always enough; screen sharing, pairing and mobbing are not ideal either, the stakeholders want to spend more time with the feature than I'm willing to spend on a call.
Your original question was, paraphrased, "how do we give non-tech product owners early access without a staging environment?"
The canonical answer, from organizations that do this, is to use feature flags that are tied to user accounts. But this requires a certain level of engineering maturity—specifically, something that looks a lot like continuous deployment.
There's a bunch of things that go along with continuous deployment, but one of them is continuous integration (the practice, not the poorly-named build servers), which is a combination of trunk-based development and frequent merges to the trunk. This requires programmers to hide incomplete work behind feature flags (or keystones¹). There's an associated set of practices for dealing with schema changes that I'd be happy to describe.
People who are using feature flags (and associated practices) don't have "code that's not ready to merge." That's the whole point of the feature flags—to allow them to merge and deploy unfinished code.
So when you put the constraint of "our code isn't ready to merge" on my "use feature flags" answer, I thought you weren't engaging in good faith, because it's kind of nonsensical—like saying risk of sunburn prevents you from using sunscreen lotion. I apologize for misconstruing. I assume what you really meant was, "We aren't able to use feature flags to merge and deploy incomplete code."
That's a perfectly fine answer! But you asked how people share incomplete work when they don't have a staging environment, and the answer is, "feature flags."² Specifically, they deploy incomplete work to production and use feature flags to selectively hide and show it. If you can't do that, then it's probably best to keep your staging environment.
¹Keystones: https://martinfowler.com/bliki/KeystoneInterface.html
²For teams that use keystones, but not feature flags, pairing with stakeholders (screen sharing) is another approach I've seen used. It has the advantage of being simpler. But I agree that it's more constraining.