Pressure-test a spec before anyone writes code

The cheapest change to a product is one made before it is built, and everyone knows that, which is why it is strange how little pressure most specifications are put under before the work starts. A document gets read by the people who agree with it, approved in a meeting, and its assumptions are discovered later, one sprint at a time.

The gap is usually not that the spec is wrong. It is that it is written from one point of view, and shipped software meets people with different jobs, different levels of confidence with technology, different needs about access, and different reasons for being there at all. The person who wrote it cannot easily hold twenty of those perspectives at once, however good they are.

That is the trick this skill performs. Twenty fixed personas, varied deliberately across background, technical confidence and accessibility needs, are put through the product as the specification describes it, and their findings are handed to a panel of five product managers with genuinely different instincts: a traditionalist, a disruptor, a design led one, a growth one and a technical one. They argue, they converge, and what comes back is a prioritised set of revisions rather than a list of opinions.

It is a simulation, and the honest framing matters. It does not replace talking to your actual customers, and anyone who tells you a synthetic panel does is selling something. What it does reliably is find the obvious problems before real people have to, so that when you do put it in front of customers you are spending their patience on the questions that genuinely need them.

The output is designed to be usable rather than admired: a findings report, a redlined PRD you can act on, and the raw persona logs so you can check the reasoning rather than trust the summary. Being able to see why a finding was made is what separates this from a confident paragraph.

It sits here because product management is half of what Pivotal Labs does, and this is what that half looks like when it is written down. The build is the easy part. Knowing what to build, and finding out cheaply that you were wrong, is the part that decides whether the software was worth making.