When I land in a new startup/scale-up, I want to have fast and deep conversations with their product and engineering teams, and have everyone walk away with a highly converged understanding at the end of the chat.

In service of this, there’s a few types of information I always find useful to get a handle on right at the start: Their internal naming conventions for foundational concepts that product and engineering rely on every day.

Three of the most basic (and most useful), are defining Effort, Size, and Fidelity.

Effort is whether we’re talking about Time Worked or Time Elapsed: If you spend 4 hours on a work item on Monday morning, then another 4 hours finishing it on Wednesday, then we have: • Effort: 8 hours • Duration: 3 days

Sizing has been done to death (so I won’t linger on it here), but it’s weirdly common to find no deeper definition beyond “Story/Task”. Simple is best here, and in the absence of something the team is already using for these concepts, I offer a T-Shirt Size baseline: • Small: Developer Day(s) of Effort (often “Task”) • Medium: Developer Week(s) of Effort (often “Story”) • Large: Developer Month(s) of Effort (Often “Epic”)

Fidelity is about understanding who will be using the output of this piece of work, and what for. I find the terms Proof of Concept, Prototype, and MVP are used in wildly differing ways in different teams/companies, so in the absence of formalised usage already existing, I offer this baseline definition:

• Proof of Concept (PoC): This is about Internal Learning for Decision Support (often it’s what results from a Spike). Not Customer Facing, Not Production-ready. This is an ultra-minimal/throwaway solution to create the “new knowledge” required for the upcoming Decision, nothing else.

• Prototype: This is about External Learning for Solution Validation. Yes it’s Customer-facing, but it’s the most minimal/throwaway solution that will get us some external validation about whether this Solution is useful/valuable to our customer/user audiences. It’s absolutely not expected to be Production-ready (although in some cases this might be the minimal path).

• MVP: This is about Launching. Fast. Really what I want from an MVP is to get a yes to this question: “Is this the smallest possible version of the Solution that someone might pay $1 or more from?”. The reason I like this definition is because I assign materially greater value to the quality of the product feedback from someone who has opened their wallet than someone who hasn’t.

Plenty of you will tell me my definitions are wrong/incorrect, and I’m totally open to this.

Sizing: Beck/Jeffries/Cohn acolytes will bristle at me linking Effort and Size. Fidelity: Ries/Cagan acolytes will flinch at my Prototype/MVP and MVP/MMP transpoitions.

I know I’m wrong, but I find these definitions easier to communicate to folks who haven’t drunk deeply of the kool aid. YMMV.