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.
🏛 Government / Public Sector☁️ SaaS & Enterprise📋 Product Management
Your Learning Sprint
Product · Now → July 2026
Six weeks. One focus area per week. 30–45 min a day is enough. Everything on this page is the reference — this is the sequence.
Week
1
Jun 11–17
What real PM looks like
Finish Empowered — find the gap between your org and what Cagan describes
📘 Reading: Finish Empowered. Pay close attention to Chapters 5 (coaching) and 8 (product culture) — that's your NYS ITS chapter.
✍️ Do: List 3 ways your org's structure makes good product work harder. Then one thing you could do this month that works within those constraints rather than against them.
Week
4
Jul 2–8
Discovery — the biggest unlock available to you
Continuous Discovery Habits — then actually talk to one agency user
📘 Reading: Continuous Discovery Habits by Teresa Torres, Chapters 1–5. The Opportunity Solution Tree is the key tool.
✍️ Do: Schedule a 30-minute conversation with one agency user. That's your first discovery session. "I talked to 5 agency users this month" is one of the most powerful sentences in a stakeholder meeting.
Week
5
Jul 9–15
Positioning — make it land for anyone
Obviously Awesome — work through the positioning canvas for your product
📘 Reading: Obviously Awesome by April Dunford (2026 edition). Do the positioning canvas exercise — allow 2 hours. It changes how you talk about everything.
✍️ Do: Write a one-page product brief for your current product — what problem it solves, for whom, what success looks like. Write it for a government director who has never heard of product management.
Week
6
Jul 16–20
Influence + roadmaps — lead without a title
Influence Without Authority — map your stakeholders and what they actually care about
📘 Reading: Influence Without Authority by Cohen & Bradford. Work through the "currencies" exercise — what do your key stakeholders actually value?
🎙 Listen: Re-listen to your favorites from the 6 episodes. Pick the one that landed hardest and listen again with fresh ears.
✍️ Do: Map your top 5 stakeholders. For each: what do they care about most? What does "success" mean to them? How does your product work serve that? This is your influence map — it lives in your Field Notes.
After week 6 → Switch to FinOps anchor (mid-June through September). Keep product alive with 20 min/week — one Lenny's episode, nothing more. Come back to product after September renewal.
Currently Reading
You're already in the right place
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.
📘
⭐ Reading Now
Empowered — Marty Cagan
Cagan's core argument: real product teams are empowered to solve problems, not just ship features. This is the exact tension you face at NYS ITS — you're trying to bring product thinking into an environment built around procurement cycles and stakeholder requirements. The chapters on product culture and working with leadership are especially relevant. The key insight to hold onto: your job is to discover what to build, not just manage how it gets built.
These are sequenced for where you are. Start with Inspired, then go into the government-specific and enterprise reads.
⭐ Read Next
PM Foundation
Inspired: How to Create Tech Products Customers Love
Marty Cagan — 2nd Edition
The prequel to Empowered. Covers how strong product teams actually work — discovery, delivery, vision, and strategy. Essential context for everything Empowered builds on. Same author, same world, more tactical.
For you: Empowered tells you how to lead a product org. Inspired tells you how to actually do the product work. Read them together.
Product in Service: A Manifesto for Pragmatic Product Management
Scott Colfer
A short, sharp manifesto (42 pages) for product management in complex service environments — government, healthcare, education. Addresses legacy systems, political constraints, procurement, and the messy human reality that standard PM books skip entirely.
For you: Written literally for your world. The opening line is basically your life: "Most product advice is for SaaS startups. This book is for everyone else." Also check his free Substack: productinservice.substack.com
How technology products move from early adopters to mainstream enterprise. The "chasm" is the dangerous gap most products fall into. Essential for understanding where any SaaS product sits in its adoption lifecycle — and how enterprise license agreements fit in.
For you: Government agencies are the late majority in Moore's model. This explains why selling to them is structurally hard — and what it takes to cross.
How to position a product so the right buyers immediately understand its value. A step-by-step process for finding your product's "secret sauce" — and communicating it to people who don't think in tech terms. Just updated with a new expanded edition in 2026.
For you: Your job partly involves explaining what a SaaS product IS to government stakeholders. This book gives you the framework to do that crisply and confidently.
How to make customer discovery a regular weekly habit, not a one-time project. Introduces the Opportunity Solution Tree — a practical visual tool for connecting user insights to product decisions without jumping straight to building.
For you: Government PMs rarely do structured discovery — which is exactly why doing it gives you an edge. This book shows you how to start small and make it stick.
How SaaS products drive their own adoption through the product itself — free trials, onboarding, activation. Covers the full PLG model, when it works, and how to think about users who succeed vs. fail with your software.
For you: As a SaaS PO, the product you work with operates within this model. Understanding PLG helps you ask smarter questions about why agencies adopt or ignore the software.
How to get things done through relationships when you have no direct power over the people you depend on. Covers reciprocity, trust-building, and navigating organizational dynamics — the real hidden curriculum of large institutions.
For you: Every page applies to NYS ITS. You have responsibility without authority across engineering, legal, procurement, and leadership. This is the playbook.
How to build roadmaps that communicate strategy and direction — not just a list of features with due dates. Covers stakeholder alignment, the "when will X be done?" trap, and how to hold the line when leadership wants dates you can't commit to.
For you: Government stakeholders want a feature delivery calendar. This book gives you the language and tools to explain why that's the wrong ask — and what to give them instead.
These are the terms you'll hear — with plain English explanations and how they apply to your world.
Productization
Taking a service or custom solution and turning it into a repeatable, scalable product with defined features and pricing.
For you: ThunderCat's software needs productization to be sold via ELA to multiple agencies, not rebuilt each time.
ELA
Enterprise License Agreement — a contract giving an organization (like NYS) broad access to a software product across departments, usually at a negotiated flat rate.
For you: This is the vehicle. Productization is what makes the software ELA-worthy.
Product Discovery
The work you do before building — figuring out what problem is worth solving and whether your proposed solution will actually work.
For you: Government often skips this. Your edge is doing it when others don't.
Product-Market Fit
When a product genuinely solves a real problem for a real market. Felt when users would be "very disappointed" without it.
For you: Has ThunderCat's product found fit with government users? That's the question ELA depends on.
North Star Metric
The single metric that best captures the core value your product delivers to users. Everything else ladders up to it.
For you: What does success look like for agencies using this software? That answer is your north star.
Outcome vs. Output
Output = what you ship. Outcome = the change that happens because of it. Strong PMs focus on outcomes.
For you: Government loves outputs (features, reports). Your job is to argue for outcomes (did it save time? reduce errors?).
OKRs
Objectives & Key Results. A goal-setting framework: Objective = where we're going, Key Results = how we'll know we got there.
For you: A way to communicate product goals in language leadership understands.
Opportunity Solution Tree
Teresa Torres' visual tool linking user needs → opportunities → solutions → experiments. Helps teams not jump straight to building.
For you: A structured way to bring discovery thinking into your government context.
Technology Chasm
Geoffrey Moore's concept: the gap between early adopters and the mainstream enterprise market. Most products die here.
For you: Government IS the late majority. Understanding this explains why selling to agencies is hard.
Podcasts
Listen while you commute
All strong signal, low noise. Start with Lenny's — it's the best general PM podcast out there.
🎙
⭐ Lenny's Podcast
Former Airbnb PM Lenny Rachitsky interviews the best product and growth leaders in tech. Deep, practical, and honest. One of the most-recommended PM podcasts period.
The Product Podcast — Government & Enterprise Episodes
Product School's podcast covers enterprise and regulated-environment PM frequently. Search their archive for government, procurement, and enterprise transformation episodes.
Wes Bush (author of Product-Led Growth) interviews PLG leaders. Tactical, SaaS-focused. Great for understanding the model you're operating in at NYS ITS.
Honest, enterprise-focused PM conversations. A recent episode features a VP of Product at Deltek (government software company) on AI and enterprise product leadership — very relevant to your world.
6 episodes hand-picked from Lenny's archive based on where you are right now. All free. Start with #1 and work down — each one maps directly to something you're navigating at NYS ITS.
Skip for now: anything tagged virality, B2C growth, fundraising, or startup founding. That's a different world. The 6 above are the ones that map directly to your NYS ITS context.
Stay Sharp
Regular reading
One or two newsletters is enough. These are the ones worth your inbox.
⭐ Newsletter
Lenny's Newsletter
Weekly deep dives on product, growth, and career. The most useful PM newsletter available. Free tier is plenty to start.
Free, comprehensive guide to SaaS product management: roadmaps, agile, metrics, team structure. Good reference when you need to explain concepts to others.
Product School has free webinars, templates, and a solid PM certification if you ever want a credential. Their enterprise PM content is especially strong.
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.
"What does a Product Owner do?"
I make sure we build the right thing, not just anything. I sit between the people who need the software and the people who build it — making sure we're solving real problems and not just checking boxes.
"What is productization?"
Taking something we've built once for one customer and packaging it so it can be sold to many customers without being rebuilt each time. Like moving from custom construction to a manufactured product.
"Why does the ELA matter for product?"
An ELA makes the software available across all agencies — but only if the product is good enough that agencies actually want to use it. My job is to make sure it's that good.
"What's the difference between PM and project manager?"
A project manager focuses on delivering on time and on budget. A product manager focuses on whether what's being delivered is the right thing in the first place. Both matter — they're just different jobs.
The Translation Menu
Product management, explained through food
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.
🍽 Chef's Special
The Product Manager's Menu
Everything you need to understand — and explain — the world of product management, served in a language everyone speaks.
✦ ✦ ✦
👨🍳
Executive Chef
The Role
The Product Manager is the Executive Chef
Responsible for the whole experience — not cooking every dish, but making sure it all comes together perfectly.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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.
💡 For you at NYS ITS: You're the executive chef for ThunderCat's software — not in the kitchen building it, but deciding what's on the menu and making sure it's right for the agencies eating it.
🧪
Test Kitchen
Product Discovery
Discovery is the Test Kitchen
You never put a dish on the menu without testing it first. The same rule applies to software features.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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.
💡 For you: When someone asks "can we add this feature?" — the discovery question is "have we tested whether users actually need it?" Run the test kitchen first.
🏪
Franchise Model
Productization
Productization is Going from Restaurant to Franchise
One great location becomes a repeatable model anyone can open anywhere.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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.
💡 For you: ThunderCat's path to an ELA is the franchise play. The software needs to be standardized enough that any NYS agency can pick it up and run with it — not a custom job every time.
🍱
Buffet Contract
Enterprise License Agreement
An ELA is the All-You-Can-Eat Contract
One negotiated price. Everyone in the building eats. No counting plates.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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.
💡 For you: Your job is making the food good enough that people keep coming back. Adoption = the buffet stays full. Poor adoption = the ELA doesn't renew.
🥗
Full vs Fed
Outcome vs. Output
Output is Serving Food. Outcome is the Guest Leaving Full and Happy.
A dish can be executed perfectly and still miss the point entirely.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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?).
💡 For you: When leadership asks "what did we deliver?" — output is your answer. When they ask "did it work?" — that's the outcome. Always know both, and push for the second one to matter.
📜
Seasonal Menu
Product Roadmap
The Roadmap is the Seasonal Menu
It shows the direction and the vision — not a binding promise of every dish, every night.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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."
💡 For you: When someone asks "when will feature X be done?" — the honest answer is "it's on the menu for this season, but we adjust based on what we learn." That's a feature, not a bug.
🪑
Full House
Product-Market Fit
Product-Market Fit is When the Restaurant is Always Full
You stop wondering if people want what you're serving — you can't keep up with demand.
▾
🍽 The Restaurant Scene
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?"
📋 In Product Terms
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.
💡 For you: Has ThunderCat found fit with government users? Ask the uncomfortable question — if we took this software away tomorrow, would agencies notice? That answer tells you where you stand.
🤝
Sous Chef
Influence Without Authority
Leading the Kitchen Without Owning the Kitchen
The sous chef doesn't own the restaurant — but nothing runs without them.
▾
🍽 The Restaurant Scene
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.
📋 In Product Terms
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.
💡 For you: Your credibility at NYS ITS is built the same way — one good interaction at a time. Every time you show up prepared, follow through, and make someone's job easier, you earn more influence than any title would give you.
The Learning Ladder
0 → 10: From curious to expert
This is your structured path — from understanding what product even is, all the way to owning the conversation in your field. Each rung has exactly what to do. Click to expand. Mark it done when you're ready to move on.
0
Level 0
What even is product management?
Zero assumptions. Start here if you've ever wondered whether you're "doing it right" — or if you need to explain your job to someone who's never heard of it.
Listen: Lenny's Podcast — "What does a great PM actually do?" (any episode tagged "fundamentals"). Drive-to-work length.
✍️
Try this: Write one sentence answering "What do I do at work?" — without using the word "manage." That sentence is the beginning of your expert positioning.
💡 For you: You already ARE a product person. This rung is about getting the language so you can say it confidently.
1–2
Levels 1–2
The vocabulary — speaking the language fluently
Discovery, delivery, roadmap, outcome, backlog, sprint, north star metric. Know what these mean, when to use them, and how to explain them without jargon.
Language▾
📖
Read: The Key Concepts section on this page — then explain each one out loud to yourself in plain English. If you can't, read it again.
📖
Read: Start Inspired by Marty Cagan — Part 1 only (first 60 pages). It defines the vocabulary in context.
✍️
Try this: Pick 3 concepts from the Key Concepts section and write the restaurant version of each in your own words. Not the ones from this page — yours.
💡 For you: You'll use this vocabulary constantly at NYS ITS. When you say "outcome not output" in a meeting and people look at you — that's the moment you know it landed.
3–4
Levels 3–4
How product teams actually work
Discovery before delivery. The difference between a feature factory and a product team. Why roadmaps fail and what to do instead.
How it works▾
📖
Read: Finish Empowered (you're reading it now). Pay special attention to Chapter 5 on coaching and Chapter 8 on product culture — that's your NYS ITS chapter.
📖
Read:Escaping the Build Trap by Melissa Perri. Short, fast, directly describes what goes wrong in large orgs. You'll recognize your workplace on every page.
✍️
Try this: Draw a simple diagram of how a feature gets requested, approved, built, and shipped at NYS ITS right now. Then mark every place where a product person should be influencing the decision. That gap is your job.
💡 For you: Most government orgs are classic "feature factories" — someone asks for a thing, it gets built, nobody asks if it worked. Recognizing this pattern is step one to changing it.
5
Level 5
Product in government — the real rules
This is where most PM education ends and your specific expertise begins. Procurement cycles, risk aversion, stakeholder hierarchy, legacy systems, and why "move fast and break things" gets you fired.
🏛 Gov Context▾
📖
Read:Product in Service by Scott Colfer — all 42 pages. It's the only book that describes your actual environment. Read it twice.
🌐
Explore:productinservice.substack.com — Colfer's free Substack. Subscribe and read back issues tagged "public sector."
✍️
Try this: List the top 3 ways your organization's structure makes good product work harder. Then list one small thing you could do this month that works within those constraints instead of against them.
💡 For you: Level 5 is your moat. The intersection of government + product + SaaS is where almost no one has deep knowledge. Getting fluent here is how you become the expert people call.
6
Level 6
SaaS, productization, and the ELA
How software becomes a product, how that product gets sold to enterprises, and what makes an ELA succeed or fail. This is the business model layer under everything you do.
☁️ SaaS + ELA▾
📖
Read:Crossing the Chasm by Geoffrey Moore — Part 2 ("The Chasm" and "The Bowling Alley"). This is the framework for understanding why government agencies adopt technology slowly.
📖
Read:Product-Led Growth by Wes Bush — Chapters 1–4. Understand the model your product operates in before going further.
✍️
Try this: Write a one-paragraph answer to: "What would make the ELA succeed at renewal?" Make it specific to your product and your agencies. This is your north star.
💡 For you: ThunderCat's ELA is not a sales problem — it's a product problem. The question is whether agencies get enough value to justify renewal. You own that answer.
7
Level 7
Discovery — figuring out the right things to build
Most government product work skips directly to delivery. Discovery is the biggest unlock available to you — and the clearest way to separate yourself from people just managing tickets.
🔍 Discovery▾
📖
Read:Continuous Discovery Habits by Teresa Torres — full book. Then pick one agency user and schedule a 30-minute conversation with them. That's your first discovery session.
🎙
Listen: Teresa Torres on Lenny's Podcast — "How to make customer discovery a habit." Practical, not theoretical.
✍️
Try this: Draw an Opportunity Solution Tree for one problem you're currently working on. Opportunity → 3 possible solutions → 1 experiment to test each. Even a rough sketch on paper counts.
💡 For you: "I talked to 5 agency users this month and here's what I learned" is one of the most powerful sentences you can say in a stakeholder meeting. Nobody else is doing this.
8
Level 8
Positioning and explaining — making it land for anyone
Your job now includes being the translator. Explaining product value to procurement people, agency directors, and budget committees who've never thought in product terms. This is a skill.
📣 Communication▾
📖
Read:Obviously Awesome by April Dunford — the new 2026 edition. Work through the positioning canvas for the product you own. It's a 2-hour exercise that changes how you talk about everything.
🍽
Practice: Use the restaurant analogies on this page. Pick the two most relevant to your current situation and use one in your next meeting — naturally, not as a presentation. Watch what happens.
✍️
Try this: Write a one-page "product brief" for your current product — what problem it solves, for whom, what success looks like, and why it matters. Write it for a non-technical government director. That's your elevator pitch.
💡 For you: The person who can make complex SaaS product value clear to government decision-makers is rare and valuable. That's the expert position you're building toward.
9
Level 9
Influence, strategy, and leading without a title
At this level you're not just doing product — you're shaping how your organization thinks about product. That takes a different set of skills than the product work itself.
🤝 Leadership▾
📖
Read:Influence Without Authority by Cohen & Bradford. Work through the "currencies" exercise — what do the people you need to influence actually value? That's what you trade in.
📖
Read:Product Roadmaps Relaunched — specifically the stakeholder alignment chapters. Practice presenting your roadmap as direction, not a promise.
✍️
Try this: Map your top 5 stakeholders. For each: what do they care about most? What does "success" mean to them? How does your product work serve that? This is your influence map.
💡 For you: In government, titles move slowly. Influence moves faster. The person who understands what everyone needs and connects the dots is the one people go to — title or not.
10
Level 10
You become the expert — and you start teaching
You have a point of view. You can see what others can't. You've synthesized government + SaaS + product into something that's genuinely yours. Now you start sharing it.
🎓 Expert▾
✍️
Write your point of view: What do you believe about how government should work with SaaS products? Start with one sentence. That's the beginning of your expert voice — on LinkedIn, in meetings, in a talk someday.
🗣
Teach one thing: Find one person in your organization — a colleague, a new hire, a stakeholder — and explain one product concept to them using your own analogy. Teaching forces you to truly own knowledge.
🌐
Connect with the field: Join Mind the Product's Slack. Post one thought. Answer one question. The community is how experts find each other.
📋
Document what you've learned: Use your Field Notes board to capture frameworks, acronyms, and hard-won knowledge. Your notes are your IP. Protect and grow them.
💡 This is where you are headed. Not someday — sooner than you think. The fact that you're asking these questions, building this hub, thinking in restaurant analogies at the intersection of government and product? You're already doing the expert work. Now it's about claiming it.
Product Learning — Joy's Hub · Built for a government SaaS PO who is building something real