What “good” looks like, and why it’s worth codifying
Most cross-functional friction gets diagnosed as a communication problem. People aren’t talking enough, the handoffs are messy, someone needs to write better tickets. That diagnosis is comforting because it implies a process fix. It also tends to be wrong. Underneath most of the friction between commercial stakeholders, product, and engineering is something harder to fix with a meeting. The three groups are working to different definitions of “good,” and those definitions tend to collide late, after people are already invested in a plan.
Non-technical, commercial stakeholders
For a non-technical stakeholder, a founder, a commercial lead, someone who has sold a roadmap to a board or a customer, good tends to mean a promise kept on a date. The product idea already exists in their head as a commitment made to someone else. Predictability is the currency. A thing that ships late but ships beautifully is still, from where they sit, a thing that shipped late.
Product stakeholders
For product, good means building what customers actually want, evidenced rather than assumed, solving the real problem rather than the one that was easiest to articulate in the kickoff. Their horizon is the problem cycle, and their failure mode is shipping something well-built that nobody needed.
Engineering stakeholders
For engineering, good means building the right thing in a way the system and the team can carry for years. Their horizon is the longest of the three. The cost they’re guarding against, accumulated complexity, the decision that’s cheap today and expensive every day after, is mostly invisible to everyone else until velocity quietly collapses.
These are not three distinct points on a single scale but different axes entirely, which is why a decision can look fast to commercial, sensible to product, and reckless to engineering all at once, with everyone correct from where they’re standing.
None of these definitions is wrong, and they aren’t even in conflict on the merits. The trouble is that they’re held tacitly and surfaced reactively. Engineering’s definition of good, the edge cases, the undefined states, the data contracts, the non-functional requirements, mostly lives in senior engineers’ heads and comes out in code review or in a planning session, which is to say after a plan already exists. To the people who made that plan, this reads as the goalposts moving. To engineering, it reads as being asked to sign off on something underspecified. Scheduling makes it worse, because an estimate is a probability distribution that gets consumed as a promise, and when reality lands in the tail, both sides quietly start padding and discounting in an arms race of mistrust.
The real cost is not the disagreement itself. It’s that the disagreement attaches to people. “Engineering is difficult.” “Product never gives us enough detail.” “Sales promises things that don’t exist.” Once a standard lives in a person rather than in an artifact, every application of that standard reads as that person being awkward, and the substance gets lost in the tribe.
How AI can begin to solve this problem
This is where I think AI changes something real, and not in the way it’s usually pitched. The interesting move is not that an agent writes better tickets. It’s that it can take a definition of good which used to live in someone’s head and turn it into an artifact, applied upstream, consistently, before anyone is committed to a plan. Early trials we’ve done have reached the point where product’s tickets go through several passes against an agent engineering built to hold their requirements. The details get found early and the social object changes completely. It’s no longer “engineering being difficult.” It’s “the review found gaps we need to fill.” The standard has been separated from the people.
That separation is most of the value. A great deal of cross-functional friction is really about who has to deliver the bad news, and a rubric inside an agent delivers it without a face attached, which means the conversation can be about the gap rather than about the person. It also makes the standard contestable in a healthy way. If the rubric is too rigid, or plainly wrong, that’s now a visible, editable thing you can argue with. The disagreement moves to where it belongs, onto the definition of good itself, rather than onto each other.
There’s a compounding effect too. Once a work packet is specified well enough to satisfy the rubric, it’s specified well enough to be machine-actionable. In our recently deployed system, the same artifact that made the ticket legible to a human can be pulled through into development automatically, with automations on the engineering side picking it up. The codified standard starts being the interface between the two worlds of engineering and product. It’s currently rudimentary in implementation, though the direction is fairly clear.
How it can be improved upon
It may be useful to be honest about where this goes wrong. The first risk is ownership. If engineering writes the rubric alone, you haven’t dissolved the friction, you’ve automated engineering’s ability to say no, faster and at scale. The richer version holds all three definitions at once, in multiple locations throughout your (AI)SDLC, so the same mechanism that asks product for a success metric can ask engineering whether it’s gold-plating something the commercial context doesn’t warrant. The standard should run in both directions, not just downhill onto product.
The second risk is that a well-formed ticket is not the same as the right thing to build. An agent can make a proposal internally consistent and complete without making it correct. It handles “is this well-specified and does it clear our bar,” not “should we be doing this at all,” and confusing the two would be a quiet way to ship well-documented mistakes. A codified standard also tends to ossify if you let it. It works best as a floor that catches the obvious gaps, rather than a ceiling that replaces the judgement of someone who knows when a rule should be broken.
What I keep coming back to is that the friction was never really about the work. It was about tacit standards colliding late and attaching to people. If you can write down what good looks like for each function, automate it with AI, surface it early, and take the person out of the messenger role, the friction loses most of what it was feeding on.
Want to talk about AI?
30-minute intro call. No commitment or cost.
