To tame AI coding chaos, INVEST in your product - 3/19

📆 Upcoming Events

Wanna volunteer? Join the events team in your city.

📰 Today's Edition:

Your AI tools can build anything in an afternoon. But are you building the right things?

I keep hearing the same thing from founders across our portfolio: we can ship faster than ever, but somehow things feel more chaotic, not less.

Here's what I think is happening: because it's easier to build, there's a temptation to skip the planning. Just prompt it and ship it. But faster execution without clear thinking doesn't get you to product-market fit faster — it just gets you to confusion faster. In practice, this shows up as context breaking across tools, decisions not being captured, and teams losing track of why something was built in the first place.

The truth is, everyone is in product now. That's probably always been the case at early-stage companies — founders wear every hat. But with AI collapsing the build cycle, the planning and coordination work that used to happen naturally during longer dev cycles now has to be intentional. Whether you're technical or not, if you're deciding what to build and why, you're doing product management. And product management is really about one thing: making sure every feature ties clearly back to a high-impact customer outcome.

My friend Doug Peete — a 30-year product veteran who's currently CPO at Atono and previously helped scale product through Everbridge's $200M+ acquisition — put it to me simply: the way you get AI to perform better is the same way you get a junior developer to perform better. Write better specs. He shared a framework with me that I've been using ever since.

INVEST: 6 questions to ask before you build anything

The INVEST framework is a checklist for evaluating whether a user story is actually ready to build. Each letter represents a quality every story should have:

  • I — Independent. It can ship on its own, without waiting on other work.

  • N — Negotiable. It defines an outcome, not a rigid implementation.

  • V — Valuable. You can name who benefits and how.

  • E — Estimable. Your team can give it a rough size. If they can't, it's too vague or too big.

  • S — Small. The smallest meaningful slice of value you can deliver.

  • T — Testable. You can write clear acceptance criteria and verify it works.

These aren't academic ideals — they're practical risk controls. And they don't just help humans – they also dramatically improve how AI systems interpret and execute work. And when AI lets you build at 10x speed, shipping without these guardrails means you can scale ambiguity just as fast as you scale execution.

What this looks like in practice

We've been building a job board for Hustle Fund portfolio companies. One of our first stories was: "candidates can view and sort jobs." Simple enough, right?

When we actually started building, that single story fractured into a dozen problems. Take just the categorization piece: a role like "Clinical Operations Manager" could reasonably live under clinical operations, customer success, or clinical jobs. Should we show it next to clinical roles at companies like Coral Care or Bicycle Health? Or should it sit alongside an Implementation Manager launching new practices at Duet? Every decision like this had downstream implications for search, filtering, and whether candidates would actually find the right roles.

Running it through INVEST, the problems jumped out:

Independent? Not even close — every piece depended on something else.

Small? Way too big. It was really five or six stories wearing a trenchcoat.

Estimable? Too many unknowns bundled together for anyone to size it.

Testable? Hard to define "done" when the scope keeps shifting.

So we broke it apart. One story for keyword search. One for the categorization model. One for manual job entry (shippable today) as a fallback while we figured out automated ingestion (a separate, future epic). Each piece was independent, small, estimable, and testable. Each one delivered a clear slice of value. The key isn’t just breaking work down – it’s making sure those decisions are captured and persist, so future teammates (or AI systems) understand why choices were made.

Try this at your next planning session

The temptation right now is to skip planning because building feels so easy. Resist it. Take your biggest current initiative and stress-test it:

  1. Can you ship it without waiting on anything else? If not, find the smallest piece that can ship alone.

  2. Have you defined the outcome or dictated the implementation? Leave room for your team (and your AI tools) to find the best path.

  3. Can you name who benefits and what changes for them? If you can't, it's not ready.

  4. Can your team give it a rough size? If they're shrugging, break it down further.

  5. Can you write three acceptance criteria right now? If not, you don't understand the story well enough yet.

Just because it's easier to build doesn't mean features shouldn't still be tied clearly back to a high-impact customer outcome. Plan first. Then build fast.

-Dunky the hippocorn

P.S. Doug and the team at Atono are building a “context layer” for product teams — connecting stories, decisions, feature adoption, and product context into a single system so teams (and AI) can move fast without losing alignment. Hustle Fund readers get special access — reach out to learn more.

🎥 Watch This

When you begin building your startup it’s likely that you are intensely focused on your product, traction, fundraising, etc. But when should you start thinking about the risk you are taking on as a founder? And what sort of risks are most relevant to your business in the early stages?

We explain more in this episode of Uncapped Notes.