Related posts
See all
Product management has always been a shape-shifting function. Every few years, the job description quietly rewrites itself. From project-manager-in-disguise, to mini-CEO, to "growth PM," to whatever we're calling it now. But the shift happening right now feels different. It's not a new flavor of PM. It's a change in how products get built, validated, and delivered.
If you're a PM or product leader still operating the way you were two years ago, the ground has moved under your feet.
Three things I've been thinking about. Three things that have changed how I work.
Prototyping Is the Job Now
If you're a PM in 2026 and you're not prototyping, you're doing it wrong.
You don't need to be a full-stack engineer. But you need to be able to take an idea, string together some tools, and produce something a customer can react to. In hours, not weeks. The era of spending two sprints writing a PRD, handing it to design, waiting for mocks, then handing it to engineering? That's done.
The tools have caught up. You can go from a rough concept to a functional, clickable prototype in an afternoon. Not a wireframe. Not a Figma mock. A real thing someone can poke at and tell you if it solves their problem.
This changes your leverage. You're not the person who writes the spec and manages the backlog anymore. You're the person who shows up to a stakeholder meeting with a working prototype and says, "Try this. Does it solve your problem?" Totally different conversation than walking someone through a slide deck.
And prototyping doesn't just make you faster. It makes you think better. When you build something, even something rough, you confront decisions you'd hand-wave past in a document. You hit the edge cases, the UX friction, the "wait, this doesn't actually make sense" moments that a PRD never surfaces.
Compress the Cycle. Get to the Customer.
We used to talk about MVP timelines in quarters. Then it became "6-8 weeks." Now Fieldguide’s product team is going from idea to user-tested MVP in a weekend. Not an exaggeration. It's happening.
The old cycle was: research, define, design, build, test, ship, learn. Each stage with its own timeline, its own handoffs, its own bottlenecks. The new cycle is: prototype, validate, iterate, ship. And the first three steps happen in days.
Why does this matter? Because the cost of being wrong in product has always been measured in time. You'd spend three months building something, ship it, discover nobody wanted it. Compressing the cycle doesn't just make you faster. It makes you less wrong, more often. You run more experiments, learn faster, converge on the right product sooner.
Your job is increasingly about velocity of learning, not precision of planning. The PM who writes the perfect spec but takes three months to validate it will lose to the PM who ships three rough prototypes in three weeks and actually talks to customers about each one.
I know the instinct. I have it too. You want to get it right the first time. Nail the spec. Anticipate every objection. But when you can validate ideas in days, that perfectionism becomes a liability. Get comfortable with "good enough to learn from."
You're Building in a Probabilistic World Now
This is the one I think PMs are least ready for. And it might be the most important.
For the entire history of software, we built deterministic systems. Click a button, a specific thing happens. Enter data, it gets stored exactly how you expect. You could write acceptance criteria like: "When the user clicks Submit, the order is created." Done.
AI products don't work like that.
When you build on large language models, you're building on a probabilistic foundation. Same input, different outputs. The system might be brilliant 95% of the time and hallucinate the other 5%. Your acceptance criteria can't be "does it do X" anymore. It has to be "how often does it do X, and what happens when it doesn't?"
That changes everything. How you spec. How you measure quality. How you define success. Traditional metrics like DAU and churn still matter, but they don't capture the whole picture. You need to care about response accuracy, hallucination rates, confidence thresholds. Most PMs have never had to think about any of this.
It goes deeper than metrics, too. How do you communicate confidence to users? How do you handle the case where the model is wrong? How do you build trust with people who are used to software that's either right or broken?
The smartest teams I've seen treat determinism as an asset, not a limitation. They build hybrid systems. AI handles the ambiguous, creative, pattern-recognition stuff. Deterministic logic handles what has to be correct every single time. Guardrails, validation layers, human-in-the-loop checkpoints. These aren't crutches. They're architecture.
For PMs, this means getting comfortable with the idea that your product will sometimes be wrong, and your job is to design the system so that "sometimes wrong" is acceptable, recoverable, and transparent.
So What Do You Do?
Pick up prototyping tools and start building. You don't need to be an engineer. You need to be someone who can go from concept to something testable in a day.
Reorient around speed of learning. Stop optimizing for the perfect plan. Optimize for the fastest path to customer feedback.
Invest in understanding probabilistic systems. How LLMs work. What confidence scores mean. What evaluation looks like for AI products. This isn't optional anymore.
The PM function has always evolved. The ones who thrive next won't be the ones who wait for the job description to update. They'll be the ones who update themselves first.
Dhruv Dhingra
VP, Product at Fieldguide
