Everything you need to become a sharper product leader — built around your actual role: SaaS product owner, government enterprise, and the enterprise license agreement world you're navigating at NYS ITS.
Currently Reading
Empowered is one of the best PM books ever written — and it directly addresses your challenge: being a product person inside a large organization that doesn't always operate like a tech company.
Read Next — In This Order
These are sequenced for where you are. Start with Inspired, then go into the government-specific and enterprise reads.
Key Concepts to Know
These are the terms you'll hear — with plain English explanations and how they apply to your world.
Podcasts
All strong signal, low noise. Start with Lenny's — it's the best general PM podcast out there.
Stay Sharp
One or two newsletters is enough. These are the ones worth your inbox.
Explain It to Anyone
Your job is partly to translate product thinking for people who've never worked that way. Here are the key framings that work in government contexts.
The Translation Menu
Every concept below has a restaurant version. Use these to explain your job to anyone — a colleague, a stakeholder, your family. Click each dish to read the full analogy.
The Executive Chef doesn't chop every vegetable or plate every dish — they design the menu, decide what the restaurant stands for, train the kitchen team, and make the call when something isn't right. They're answerable to the owner and the customers. A bad dish goes back. A great service night is a team effort they orchestrated.
A Product Manager doesn't write every line of code or design every screen — they define what gets built and why, set the vision, work with engineering, design, and stakeholders, and make judgment calls when priorities conflict. They're accountable to leadership and users. A feature that misses the mark gets reworked. A successful launch is a team win they shaped.
Before a new dish hits the menu, the chef experiments in the test kitchen. They try different flavor combinations, get feedback from the team, adjust the seasoning, maybe scrap the whole idea and start over. This process is invisible to customers — but it's what separates a dish that lands from one that flops on opening night.
Product discovery is the work you do before building — user interviews, prototypes, small experiments. You're testing whether a feature is actually worth building before spending months on it. Most government teams skip the test kitchen and go straight to cooking for a crowd. That's why features launch and no one uses them.
A beloved local restaurant makes incredible food. But every night is a custom performance — the chef improvises, the menu changes, it only works because of this specific team in this specific kitchen. To become a franchise, you have to standardize everything: recipes, processes, training, equipment. You trade some spontaneity for something that can scale — the same great meal, reproduced reliably in 50 cities.
A custom software project is the local restaurant — built for one client, by hand, every time. Productization means packaging that solution into a repeatable product with defined features, pricing, onboarding, and support. You trade custom flexibility for something that can be sold to 50 agencies without rebuilding from scratch each time.
Imagine a company negotiates a deal with a buffet restaurant: "We'll pay you a flat annual fee, and all 3,000 of our employees can eat there whenever they want — no per-plate charges, no individual billing." The restaurant wins guaranteed revenue. The company wins flexibility and scale. But it only works if the buffet has food people actually want to eat, or nobody shows up and the deal dies at renewal.
An Enterprise License Agreement is NYS paying one negotiated price for all agencies to access ThunderCat's software — no per-seat counting, no individual procurement per agency. The state wins scale and simplicity. ThunderCat wins guaranteed revenue. But the ELA only survives renewal if agencies are actually using and valuing the product. A bad product in an ELA is a buffet with food nobody eats — the contract dies quietly.
A kitchen can serve 200 perfectly plated dishes in a night — that's the output. But if guests are leaving hungry, or complaining the portions were tiny, or the dish didn't match what they ordered, the output didn't create the outcome. The restaurant succeeded at execution and failed at the actual goal: a satisfied guest who comes back.
A team can ship 20 features in a quarter — that's output. But if users aren't actually doing their jobs faster, making fewer errors, or getting more value from the software, the output didn't create any outcome. Government loves to measure output (features shipped, tickets closed). Product managers fight to measure outcomes (did it change behavior? did it save time? did it reduce processing errors?).
A seasonal menu says "this fall, we're focusing on root vegetables and warm, comforting dishes." It sets the direction — guests know what to expect. But if a supplier runs out of parsnips, the chef substitutes. If a dish tests poorly, it gets pulled before launch. The menu communicates the vision. It's not a legal contract promising exactly these 12 dishes on exactly these dates.
A product roadmap says "this quarter we're focusing on onboarding and reporting features." It sets direction for the team and stakeholders. But if user research reveals a bigger problem, you adjust. If a feature is harder than expected, priorities shift. The roadmap communicates strategy — it's not a feature-delivery promise. Government stakeholders often want it to be the promise. Your job is to hold the line on "direction, not contract."
Before product-market fit, the restaurant is guessing. Is the menu right? Is the location right? Tables sit half-empty. After product-market fit, there's a line out the door. Regulars bring their friends. People are disappointed if they can't get a reservation. You're not asking "will people come?" anymore — you're asking "how do we serve everyone who wants to come?"
Before product-market fit, you're pushing the software on users. After it, users are pulling — asking for more access, complaining when it's down, genuinely frustrated if they lose it. The clearest test: would your users be "very disappointed" if the software went away? If the honest answer is "probably not," you haven't found fit yet.
The sous chef coordinates the pasta station, the grill, the garde manger — none of whom report to them on paper. They can't fire anyone. They don't set budgets. But they earn trust station by station, communicate clearly under pressure, and make sure the whole kitchen moves as one. Their influence is built on competence and relationships, not a title.
A Product Manager has no direct authority over engineering, design, legal, or procurement. But they have to coordinate all of them. The only way this works is through trust, clarity, and relationships built over time. You can't order people to do things — you have to make them want to. In government, this is even more true: the hierarchy is deeper and the walls between departments are higher.