# ProductFTW > A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### About ProductFTW URL: https://www.productftw.com/about/ Last updated: 2026-05-24T02:35:25.000Z Welcome to Product For The Win (ProductFTW): a unique newsletter about product management in technology startups. ProductFTW is exclusively advice about how to get shit done because, in the end, product management is about shipping valuable software. Everything else is noise. ### Our Mission We're on a mission to share the nitty-gritty, real-world insights to help you rock it as a product leader. We're not here to preach from the ivory towers of big tech giants. We're all about keeping it real and relatable for founders and product leaders in the trenches of startups and smaller companies. ### Why we started this blog So, why are we doing this? Well, let's start with a little confession. We've been inspired by many of the great names in the world of product management. Those folks are fantastic, no doubt about it. But here's the kicker: we often found ourselves nodding to their wisdom while thinking, "That's great, but how on earth does this apply to us in our role?" We get it. It's not that we didn't appreciate the insights from the big shots, but sometimes it felt like trying to fit a square peg into a round hole. While impressive, their advice, experiences, and stories didn't always align with our realities as product managers in smaller companies and startups. So, we decided to do something about it. We're here to bring you a fresh perspective, one that's firmly rooted in the real-world challenges and opportunities that you encounter. ## The ProductFTW Team ProductFTW is brought to you by [Totavi, LLC](https://www.totavi.com/?ref=productftw.com) and friends. ## Matthew Goldman [Matthew](https://www.linkedin.com/in/matthewgoldman/?ref=productftw.com) is the Founder of Totavi, a boutique product strategy consulting firm. He started his journey into building technology products in middle school in the mid-1990s, working at technology startups after school and during the summer through his first business, a web design and network administration company. Matthew's first real job as a Product Manager was at Green Dot Corporation in 2006, as employee number 65 or so. At Green Dot, Matthew learned everything he could about retail and payments, working with some of the world's largest retailers to build real-time cash acceptance networks. Since then, Matthew has been a founder and CEO of two venture-backed companies (and sold them), a Chief Product Officer at a billion-dollar public company and a 100-person Series B startup, and a host of other product roles. He has also been fortunate to work with many brilliant product managers, including the other voices in this newsletter. ## Ellen Dearborn [Ellen](https://www.linkedin.com/in/ellendearborn/?ref=productftw.com) is a Principal at Totavi, joined the firm after more than a decade of progressively growing roles as a Product Manager, Director, and Vice President of Product. Ellen transitioned from a product operations role at Bankrate to a product manager and joined Matthew's nascent product team at the company. She has since worked as a founder, a startup's only PM, a data PM in a huge organization, and a product leader in a startup. Ellen's broad experience enables her to understand the unique challenges of zero-to-one products and how to rebuild applications and enhance performance and capability. She has quickly become the go-to resource for accurate knowledge and effective organizational output. ## Zach Bartholomew [Zach](https://www.linkedin.com/in/zachary-bartholomew/?ref=productftw.com) is a Principal at Totavi, joining the firm after a decade in fintech spanning card issuance, payment processing, and financial data infrastructure. He started his career as a software engineer at AT&T (Matthew and Zach worked there simultaneously but didn't know each other!) and was a product owner for the first time at Heartland Payment Systems before joining Matthew's team at Bankrate in 2016. Since Bankrate, Zach has co-founded a company (with Ellen), led products for The Points Guy, scaled a card issuance platform at Apto Payments—where the team last reunited—and most recently served as VP of Product and Engineering at Perigon, building AI-powered data pipelines serving financial services clients. Zach brings a builder's perspective to consulting, having shipped code and led teams at every stop. ## Jessica Marquez [Jessica](https://www.linkedin.com/in/jessicasomething/?ref=productftw.com) is a Principal at Totavi, working with our clients to implement new solutions. Jessica's startup career began in product marketing, and she shifted to her first Product Manager role at Wallaby Financial, where she was the first PM hired by Matthew. As the core Wallaby product owner, Jessica showed her execution capabilities in building an award-winning consumer mobile personal finance app. Jessica has honed her broader skills outside of work as a leader in the Junior League and took a detour in core business operations as Director, Business Operations at Apto Payments, where the team last reunited. Outside of work, Jessica finds creative inspiration in pottery-making and volunteers as a tax preparer for transitional-age foster youth. ### Product FTW Templates URL: https://www.productftw.com/templates/ Last updated: 2026-09-03T15:35:03.000Z **Product Decision Log Template** A simple template for documenting product decisions, who made them, the options considered, and why the decision was made. Use when: You need to keep decisions organized across a project, maintain context as requirements evolve, or avoid revisiting decisions that have already been made. [View Guide](https://www.productftw.com/templates-product-decision-log/) --- **Product Requirements Document** A practical template for defining the problem, goals, requirements, scope, success metrics, and implementation details needed to align product, design, and engineering. Use when: You need to turn an idea into a clear execution plan, align stakeholders, or prepare a feature for development. [View Guide](https://www.productftw.com/templates-product-requirements-document/) --- **How to Conduct User Interviews** A practical framework for planning, running, and synthesizing user interviews that lead to better product decisions. Use when: You need to validate assumptions, understand customer behavior, uncover pain points, or improve a product experience. [View Guide](https://www.productftw.com/templates-how-to-conduct-user-interviews/) --- **Product Brief Template** A simple structure for writing briefs that align teams quickly. Use when: You need to frame a feature, opportunity, or technical request. [View Template](https://www.productftw.com/templates-product-brief/) --- **API Evaluation Checklist** How to evaluate an API as a PM using five practical checks. Use when: You need to pick a vendor or ask engineering the right questions. [View Checklist](https://www.productftw.com/templates-api-evaluation-checklist/) --- **Fintech Development Checklist** A checklist of failure modes that routinely break fintech systems. Use when: You are launching, triaging an incident, or reviewing a postmortem. [View Checklist](https://www.productftw.com/templates-fintech-breakage-checklist/) --- *This is one of the ProductFTW field guides — curated paths through the archive. Explore them all:* [*Product Requirements*](https://www.productftw.com/product-requirements/)*,* [*Product Leadership*](https://www.productftw.com/product-leadership/)*,* [*Product Talks*](https://www.productftw.com/product-talks/)*,* [*Fintech Product Management*](https://www.productftw.com/fintech-product-management-guide/)*, and *Templates*.* ### API Evaluation Checklist for Product Managers URL: https://www.productftw.com/templates-api-evaluation-checklist/ Last updated: 2026-01-06T15:29:20.000Z _This page is for subscribers only._ ### Product Brief Template URL: https://www.productftw.com/templates-product-brief/ Last updated: 2026-01-06T15:41:59.000Z A simple template for early-stage alignment in the Strategy phase of the PDLC. _This page is for subscribers only._ ### Fintech Development Checklist URL: https://www.productftw.com/templates-fintech-breakage-checklist/ Last updated: 2026-01-06T15:34:10.000Z _This page is for subscribers only._ ### How to Conduct User Interviews URL: https://www.productftw.com/templates-how-to-conduct-user-interviews/ Last updated: 2026-05-21T15:56:37.000Z With Questions & Template _This page is for subscribers only._ ### Product Talks URL: https://www.productftw.com/product-talks/ Last updated: 2026-06-04T19:32:41.000Z **Interviews with product leaders who've actually shipped.** Product Talks is a series of one-on-one interviews with experienced product leaders. Each guest is an operator we've worked with personally — at AT&T Interactive, Bankrate, Wallaby, Totavi, and other places — now running product at HopSkipDrive, Smartsheet, The Zebra, Criteria Corp, perigon°, and ClosedLoop AI. The interviews cover the unglamorous parts of the job: hiring decisions, saying no, working with engineers, building when the product already exists, and what they'd do differently. --- ### Corey McMahon — Chief Product & Technology Officer, HopSkipDrive > One of my strengths is operating from first principles and envisioning a future state. That superpower can also be your kryptonite. AT&T Interactive alumnus running product, design, and engineering at the on-demand transit company for kids. [Read the interview →](https://www.productftw.com/productftw-33-product-talks-with-corey/) ### Dave Lifson — Chief Product Officer, ClosedLoop.AI > A pre-product-market-fit startup should not hire a CPO, and you should not try to be the CPO for that company. The first guest in the series. Former founder of Postling, now CPO at an Austin healthtech startup. [Read the interview →](https://www.productftw.com/product-talks-with-dave/) ### Ellen Dearborn — Product Principal, Totavi > I actually don't think that there has been a lot of evolution in product management over the last ten years. Joined the team through a re-org at Bankrate after the Wallaby acquisition. Now a key part of Totavi. [Read the interview →](https://www.productftw.com/productftw-48-product-talks-with-ellen-dearborn/) ### Felix Del Rosario — VP of Product, The Zebra > We went to the moon and there were no product managers involved. I have a slight fear that Product is not a 20-year career from where we stand today. A soccer-field friendship turned into a deep conversation about how universal product methodology can be across industries. [Read the interview →](https://www.productftw.com/productftw-40-product-talks-with-felix-del-rosario/) ### Greg Isaacs — Chief Product Officer, Criteria Corp > Structured interviews are twice as predictive as unstructured interviews. The data has shown that, over decades. Multiple-time CPO running product at an assessments-and-hiring platform. Particular depth on hiring for product roles. [Read the interview →](https://www.productftw.com/productftw-35-product-talks-with-greg/) ### Jessica Marquez — Product Principal, Totavi > I see product managers sitting on a fence post, where all the different lanes come together, with their heads a little bit above where they can scan the horizon and help with coordination. MG's first product hire at Wallaby. On running product in early-stage fintech, and the storytelling-as-product-management muscle. [Read the interview →](https://www.productftw.com/productftw-39-product-talks-with-jessica-marquez/) ### Justin Bauer — Former Chief Product Officer, Amplitude > 20% of every PM's time should be spent talking to customers. A lot of people hear that and they're shocked — it's a whole day a week. Scaled Amplitude from $1M to $300M ARR over eight and a half years. On going multi-product, founder-led sales, and what changes when you hand off to the sales team. [Read the interview →](https://www.productftw.com/productftw-38-product-talks-with-justin-bauer/) ### Matthew Goldman — Founder, Totavi > If you want to get into product, you need to build a product yourself. The people who have the title and are bad at it have learned about it entirely inside large organizations where they don't have enough true responsibility for the outcome. The tenth and final guest. Career across Green Dot, AT&T, Wallaby, Vertical Finance, and Bankrate. Interviewed by Ellen Dearborn. [Read the interview →](https://www.productftw.com/productftw-50-product-talks-with-matthew-goldman/) ### Meredith Brown — VP, Product Management, Smartsheet > Sometimes product managers come into their career thinking they have to do everything. You have so many smart people on your team — why would you do that? Look at how you can get the best out of everyone. Former AT&T Interactive colleague. Career through Salesforce and CPO at Pantheon before Smartsheet. Sports-team analogies throughout. [Read the interview →](https://www.productftw.com/product-talks-with-meredith/) ### Zach Bartholomew — VP of Product, perigon° > I don't feel like there's a general-purpose product manager role out there for too long. I think you need to be specialized. Almost wasn't hired at Bankrate. Went on to be a founder, head of product, and a regular ProductFTW contributor. [Read the interview →](https://www.productftw.com/productftw-45-product-talks-with-zach-bartholomew/) --- *This is one of the ProductFTW field guides — curated paths through the archive. Explore them all:* [*Product Requirements*](https://www.productftw.com/product-requirements/)*,* [*Product Leadership*](https://www.productftw.com/product-leadership/)*, *Product Talks*,* [*Fintech Product Management*](https://www.productftw.com/fintech-product-management-guide/)*, and* [*Templates*](https://www.productftw.com/templates/)*.* ### Product Management Leadership & Career Guide URL: https://www.productftw.com/product-leadership/ Last updated: 2026-06-11T23:51:33.000Z **A working guide to the PM role, the people around it, and the career path through it.** Product management is a job that doesn't look the same in any two companies — which is why every PM we've worked with has a slightly different definition of the work. What stays constant: you're responsible for figuring out the most important problem to solve, then influencing the team to solve it well, without being anyone's boss. This guide collects ProductFTW's most-read essays on three things: what the job actually is, how to lead without authority once you're in it, and how to navigate the hiring side from either chair. It's organized by the questions we get asked most. Skip to whichever applies. --- ## What is a product manager? A reasonable starting point. PMs do different things at every company, but the underlying job — figure out the right problem to solve, then bring the team along to solve it — is consistent. - [What is a Product Manager? →](https://www.productftw.com/productftw-1-what-is-a-product-manager/) --- ## Becoming a PM (especially the first PM at a startup) There are no entry-level PM jobs in the traditional sense. The most common path in is to be already on the team — in marketing, ops, or engineering — and to organically take on the work until the title catches up. That's especially true if you're joining as the first PM at a startup, where the role doesn't exist yet and you're going to define what it is. - [Being the First Product Manager →](https://www.productftw.com/productftw-4-being-the-first-product-manager/) - [Being the First Product Manager, Part II →](https://www.productftw.com/productftw-5-being-the-first-product-manager-part-ii/) - [Do Startups Need Product Managers? →](https://www.productftw.com/productftw-70-do-startups-need-product-managers/) --- ## What PM is — and isn't The most common confusion is project manager vs product manager. Project managers run schedules; product managers decide what to build and why. Then there's the technical/non-technical question, which gets argued endlessly and doesn't matter as much as most people think. - [Product, Project, Program Managers, and Owners →](https://www.productftw.com/productftw-69-project-product-program-managers-and-owners/) - [Project Management (Not Product Management) →](https://www.productftw.com/productftw-19-project-management-not-product-management/) - [Should Product Managers Be Technical? →](https://www.productftw.com/productftw-18-should-product-managers-be-technical/) - [The Balance Between Product and Technical Leadership →](https://www.productftw.com/productftw-52-the-balance-between-product-and-technical-leadership/) --- ## Leading without authority The hardest thing about being a PM is that no one reports to you. You influence engineering, design, sales, marketing, and the CEO without being anyone's boss. That takes data, clear writing, emotional intelligence, and a strong stomach for the word "no" — which you'll be saying and hearing more than you expect. - [Leading Without Authority →](https://www.productftw.com/productftw-11-leading-without-authority-as-a-product-manager/) - [How to Effectively Communicate as a Product Manager →](https://www.productftw.com/productftw-6-how-to-effectively-communicate-as-a-product-manager/) - [Building Confidence in Saying "No" →](https://www.productftw.com/productftw-7-building-confidence-in-saying-no/) --- ## Hiring product managers If you're building a product org, the first PM hire is the most important one you'll make. Don't fall for the "unicorn" archetype that's supposed to be technical, strategic, design-literate, and a great communicator all at once. And know when you actually need a head of product — it's later than VCs will tell you. - [When Should Your Startup Hire a Head of Product? →](https://www.productftw.com/productftw-73-when-should-your-startup-hire-a-head-of-product/) - [Stop Hiring a Two-for-One Unicorn →](https://www.productftw.com/stop-hiring-a-two-for-one-unicorn/) - [My #1 Interview Question →](https://www.productftw.com/productftw-54-my-1-interview-question/) --- ## Getting hired as a product manager From the candidate side: PM job hunting today looks nothing like it did pre-COVID. Here's what worked. - [PM Job Hunting: A Firsthand Account →](https://www.productftw.com/navigating-job-hunting-as-a-product-manager-in-2024-a-firsthand-account/) --- ## Growing your career You don't graduate from being a PM — the job stays hard, just in different ways as you get more senior. Two regular practices that help: asking yourself the same set of questions every quarter, and being honest about where you sit on a performance matrix. - [The Product Management Career Path →](https://www.productftw.com/the-product-management-career-path/) - [The Ten Questions I Always Ask Myself →](https://www.productftw.com/productftw-57-the-ten-questions-i-always-ask-myself-as-a-product-manager/) - [The Nine-Box Matrix →](https://www.productftw.com/productftw-59-the-nine-box-matrix/) - [How to Thrive When the Product Already Exists →](https://www.productftw.com/productftw-74-how-to-thrive-as-a-product-manager-when-the-product-already-exists/) --- *This is one of the ProductFTW field guides — curated paths through the archive. Explore them all:* [*Product Requirements*](https://www.productftw.com/product-requirements/)*, *Product Leadership*,* [*Product Talks*](https://www.productftw.com/product-talks/)*,* [*Fintech Product Management*](https://www.productftw.com/fintech-product-management-guide/)*, and* [*Templates*](https://www.productftw.com/templates/)*.* ### How to Write Product Requirements: A Field Guide for Product Managers URL: https://www.productftw.com/product-requirements/ Last updated: 2026-06-04T19:32:38.000Z **A field guide to the process of writing product requirements, organized by the six phases that show up in every cycle.** The classic [tire-swing cartoon](https://www.productftw.com/productftw-2-the-tire-swing-cartoon/) is funny because it's true: every step of the requirements process loses something. The customer described one thing, the project manager interpreted another, the analyst designed a third, the developers built a fourth, the deployed product was a fifth, and what the customer actually needed was a tire on a rope. The cartoon is also a useful frame for the work. Writing good product requirements is a process of staying close to the actual problem at every step from idea to release. This guide collects ProductFTW's writing on that process, organized into six phases that show up in every product cycle: figure out the problem, write the brief, write the PRD, draw the diagrams, handle the edge cases, and ship + learn. --- ## Phase 1: What's the problem? Most requirements failures aren't writing failures — they're problem-definition failures. The wrong thing gets designed because the wrong question was asked, or asked of the wrong person. Before you write a line of a PRD, you need to know who has the problem, why it's worth solving, and what failure would look like. - [The Tire Swing Cartoon →](https://www.productftw.com/productftw-2-the-tire-swing-cartoon/) - [User Problems →](https://www.productftw.com/productftw-25-user-problems/) - [Determining the Problem to be Solved →](https://www.productftw.com/productftw-12-determining-the-problem-to-be-solved/) - [For Whom Are You Building →](https://www.productftw.com/productftw-17-for-whom-are-you-building/) - [The Biggest Mistake You Can Make During User Interviews →](https://www.productftw.com/the-biggest-mistake-you-can-make-during-user-interviews/) - [You Don't Have a Roadmap Problem. You Have a Problem-Definition Problem. →](https://www.productftw.com/productftw-77-you-dont-have-a-roadmap-problem-you-have-a-problem-definition-problem/) --- ## Phase 2: The brief The product brief is the bridge between problem and solution. It's not a PRD — it's the document where you commit to what you're solving (and what you're not), define success, and scope down to an MVP that's defensible. - [The Product Brief →](https://www.productftw.com/productftw-29-the-product-brief/) - [The MVP →](https://www.productftw.com/productftw-61-the-mvp/) --- ## Phase 3: The PRD This is where most PM writing actually happens. The PRD describes the system you're building: what it does, who uses it, what edge cases matter, and how each piece connects. A good PRD is detailed enough that engineers can implement it without ambiguity but doesn't pre-design the implementation. - [Mastering the Art of Requirements: PRDs that Actually Work →](https://www.productftw.com/mastering-the-art-of-requirements-prds-that-actually-work/) - [User Stories →](https://www.productftw.com/productftw-15-user-stories/) - [Tips for Terrific Tickets →](https://www.productftw.com/productftw-21-tips-for-terrific-tickets/) --- ## Phase 4: Diagrams A good flow diagram saves a thousand words of PRD prose. The tradeoff is: it has to be readable. - [What Makes a Good Flow Diagram? →](https://www.productftw.com/productftw-47-what-makes-a-good-flow-diagram/) --- ## Phase 5: Edge cases Most software ships its happy path and gets surprised by the other 95% of real usage. Identifying edge cases is product work, not just QA work — they belong in the requirements doc, not just in the bug tracker. - [The Unhappy Path →](https://www.productftw.com/productftw-58-the-unhappy-path/) - [Ten Things That Always Break →](https://www.productftw.com/productftw-51-ten-things-that-always-break/) --- ## Phase 6: Launch and learn The work doesn't end at ship date. Knowing when to launch, writing release notes that users actually read, and managing the bugs that surface afterward are all part of the requirements lifecycle. - [Knowing When to Launch →](https://www.productftw.com/productftw-53-knowing-when-to-launch/) - [The Importance of Release Notes →](https://www.productftw.com/productftw-56-the-importance-of-release-notes/) - [Bug Handling →](https://www.productftw.com/productftw-36-bug-handling/) --- ## Cross-cutting: team norms Two practices that don't fit a single phase but show up in every one of them: working agreements that prevent re-litigating the same arguments, and decision logs that scale your judgment beyond the room. - [The Importance of Working Agreements →](https://www.productftw.com/productftw-60-the-importance-of-working-agreements/) - [Decisions Without Context Don't Scale →](https://www.productftw.com/productftw-76-decisions-without-context-dont-scale/) --- *This is one of the ProductFTW field guides — curated paths through the archive. Explore them all: *Product Requirements*,* [*Product Leadership*](https://www.productftw.com/product-leadership/)*,* [*Product Talks*](https://www.productftw.com/product-talks/)*,* [*Fintech Product Management*](https://www.productftw.com/fintech-product-management-guide/)*, and* [*Templates*](https://www.productftw.com/templates/)*.* ### Fintech Product Management URL: https://www.productftw.com/fintech-product-management-guide/ Last updated: 2026-06-04T19:32:43.000Z Most product management advice is written as if every product were a to-do app. Fintech isn't. When your product moves money, stores identity, or extends credit, the constraints come first, and the features come second. The regulators, the card networks, the bank partner, and the fraud team all have a say before a single user does. This guide organizes ProductFTW's fintech writing into the things that actually make the job different — written by people who built card, payment, and banking products at Apto, Wallaby, The Points Guy, Green Dot, and Bankrate. If you're a PM moving into fintech, or a generalist PM who just inherited a payments surface, start here. ## Identity is the product, not a login screen In consumer apps, authentication is a sign-up form. In fintech, it's a regulated requirement: you're proving a real person is who they claim to be, and getting it wrong can lead to fraud losses, compliance findings, or both. The PM owns the tradeoff between friction and risk on every flow. - [Building User Authentication →](https://www.productftw.com/productftw-46-building-user-authentication/) - [Authentication in Fintech →](https://www.productftw.com/productftw-66-authentication-in-fintech/) ## Card economics are product decisions The features that feel like "settings" in a card product — how repayment works, when rewards post, which payment options you surface — are actually economic levers. Each one changes the program's unit economics and how users behave. A card PM who treats these as someone else's spreadsheet ships products that lose money or confuse customers. - [Why Credit Card Payment Options Confuse Users →](https://www.productftw.com/productftw-67-why-credit-card-payment-options-confuse-users/) - [Credit Card Repayment Timing Is a Product Decision →](https://www.productftw.com/productftw-68-credit-card-repayment-timing-is-a-product-decision/) - [Why Rewards Timing Matters →](https://www.productftw.com/productftw-71-why-rewards-timing-matters/) ## Compliance isn't another team's problem The legal and compliance files aren't paperwork you hand off; they're product requirements with legal force. KYC, BSA, and the bank partner's audit ask: the PM who understands what the legal team will need and builds for it from the start, ships on time. The one who treats it as a launch-week surprise doesn't ship at all. - [Managing the Legal Files →](https://www.productftw.com/productftw-41-managing-the-legal-files/) ## You can't ship a card product like a software product Move-fast-and-break-things is a great way to lose your bank sponsor. Fintech products carry irreversible consequences (real money, real credit decisions, real regulators), so the operational discipline is fundamentally different from a SaaS release cadence. - [Why Card Products Can't Ship Like AI Products →](https://www.productftw.com/productftw-80-why-card-products-cant-ship-like-ai-products/) ## Support is a product surface, not a cost center When something goes wrong with someone's money, the support experience *is* the product. In fintech, great support isn't a nicety: it's how you keep the trust that makes the whole relationship possible. - [Why Great Support Creates Loyal Users →](https://www.productftw.com/productftw-44-why-great-support-creates-loyal-users/) ## Go deeper into*,* the card industry ProductFTW's sister publication, [CardsFTW](https://www.cardsftw.com/?ref=productftw.com), covers the credit and debit card industry from the inside: network economics, co-brand deals, interchange, program management. If the fintech PM role is your destination, CardsFTW is where you learn the business your product lives inside. --- *This is one of the ProductFTW field guides — curated paths through the archive. Explore them all:* [*Product Requirements*](https://www.productftw.com/product-requirements/)*,* [*Product Leadership*](https://www.productftw.com/product-leadership/)*,* [*Product Talks*](https://www.productftw.com/product-talks/)*, *Fintech Product Management*, and* [*Templates*](https://www.productftw.com/templates/)*.* ### ProductFTW Reading List URL: https://www.productftw.com/productftw-reading-list/ Last updated: 2026-06-05T21:18:34.000Z In addition to your weekly read of *ProductFTW*, we've pulled together a list of books we love on product management, building and shipping software, leadership, and the craft of the job. *Affiliate disclosure: the book links above go through Bookshop.org, where ProductFTW is an affiliate. Bookshop.org supports independent bookstores; if you buy through these links we may earn a small commission at no additional cost to you, which helps fund the newsletter. We only list books we genuinely recommend.* ### Guides URL: https://www.productftw.com/guides/ Last updated: 2026-06-05T21:26:43.000Z ProductFTW is organized into field guides: curated paths through the archive on a single topic, each bringing together the best posts with a brief framing. Start with whichever matches what you're working on. ## Field Guides [**Product Requirements**](https://www.productftw.com/product-requirements/): How to define and write what to build; problem framing, briefs, PRDs, diagrams, edge cases, launch. [**Product Leadership & Career**](https://www.productftw.com/product-leadership/): Growing as a PM and a leader; hiring, levels, decision-making, and staying sharp. [**Fintech Product Management**](https://www.productftw.com/fintech-product-management-guide/): What card, payment, and banking PMs actually do; identity, card economics, compliance, and shipping discipline. [**Product Talks**](https://www.productftw.com/product-talks/): Our interview series with product leaders on how they actually work. ## Resources [**Templates**](https://www.productftw.com/templates/): Ready-to-use PM templates and checklists: product briefs, API evaluation, fintech breakage, and user interviews. [**Reading List**](https://www.productftw.com/productftw-reading-list/): Books we recommend on product management, leadership, and building software. ### Product Requirements Document Template URL: https://www.productftw.com/templates-product-requirements-document/ Last updated: 2026-06-25T15:57:34.000Z A practical template for planning features in the Development phase of the PDLC. _This page is for subscribers only._ ### Product Decision Log Template URL: https://www.productftw.com/templates-product-decision-log/ Last updated: 2026-09-03T15:33:47.000Z A clear, searchable record of what your team decided, why they decided it, and who was involved. _This page is for subscribers only._ ## Posts ### 10 Most Popular Product Management Posts - ProductFTW #100 URL: https://www.productftw.com/10-most-popular-product-management-posts-productftw-100/ Last updated: 2026-10-08T16:15:55.000Z Before we get into #100, a quick programming note: ProductFTW is taking the next two weeks off. After 100 issues, it feels like a good time for a short break. We’ll be back with ProductFTW #101 in a couple of weeks. 🎉 I’ll also be at Money20/20 in Las Vegas later this month. If you’re going and want to talk product, fintech, cards, payments, or anything else I’ve writen about here, [grab 15 minutes with me](https://book.vimcal.com/p/ellendearborn/15min-f153d?ref=productftw.com). Now, back to #100. ![ProductFTW 100th issue graphic featuring the 10 most popular product management posts.](https://www.productftw.com/content/images/2026/10/productftw100.jpg) Should we make swag? Over the last 100 issues, we’ve written about product requirements, user research, technical leadership, career growth, bugs, edge cases, fintech, and a lot of the messy parts of building products that don’t always make it into the product management books. For our 100th issue, we’re looking back at the ProductFTW posts you’ve read the most. Some of these go all the way back to the beginning. Others are relatively new. Together, they’re a pretty good representation of what ProductFTW has become. Here are the 10 most popular ProductFTW posts. ## **1\. The Tire Swing Cartoon - ProductFTW #2** We’re going all the way back to issue #2 for the most popular ProductFTW post. The tire swing cartoon has been around forever, but I still think it’s one of the best illustrations of what can go wrong when building a product. A customer asks for one thing, everyone involved interprets it differently, and somehow we end up building something else entirely. The lesson is still relevant: understanding what someone actually needs is much harder than it sounds. ⁠[Read The Tire Swing Cartoon](https://www.productftw.com/productftw-2-the-tire-swing-cartoon/) ## **2\. The Unhappy Path - ProductFTW #58** Product teams spend a lot of time thinking about the happy path. The user signs up. The payment works. The API responds. Everything behaves exactly as expected. Real users have other plans. The unhappy path is what happens when something goes wrong, and those experiences deserve just as much product attention as the ones where everything works perfectly. ⁠[Read The Unhappy Path](https://www.productftw.com/productftw-58-the-unhappy-path/) ## **3\. The Product Management Career Path - ProductFTW #84** Product management has a weird career path. At a lot of companies, moving up eventually means becoming responsible for people instead of products. The problem is that managing people and being an excellent product manager are two very different skill sets. This post looks at what progression in product management can look like and why management shouldn’t be the only path available to great product people. ⁠[Read The Product Management Career Path](https://www.productftw.com/the-product-management-career-path/) ## **4\. Bug Handling - ProductFTW #36** Every product has bugs. What matters is what happens after you find them. Which bugs get fixed immediately? Which ones can wait? Who decides how important they are? How do you weigh a frustrating customer experience against everything else sitting in the backlog? Bug handling sounds like an engineering process, but there are a surprising number of product decisions hiding inside it. ⁠[Read Bug Handling](https://www.productftw.com/productftw-36-bug-handling/) ## **5\. Decision Fatigue - ProductFTW #42** Product managers make a ridiculous number of decisions. Some are obviously important. Others feel tiny until six months later when someone asks why the product works a certain way, and you realize that tiny decision became permanent. This post is about decision fatigue, how it affects product managers, and why we need to be more deliberate about where we spend our decision-making energy. ⁠[Read Decision Fatigue](https://www.productftw.com/productftw-42-decision-fatigue/) ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **6\. The Balance Between Product and Technical Leadership - ProductFTW #52** The relationship between product and engineering can make or break a product team. The best partnerships I’ve seen have clear ownership without building a wall between product and technical leadership. Both sides should challenge each other, bring different expertise to the problem, and understand where each person should lead. ⁠[Read The Balance Between Product and Technical Leadership](https://www.productftw.com/productftw-52-the-balance-between-product-and-technical-leadership/) ## **7\. Why Credit Card Payment Options Confuse Users - ProductFTW #67** Minimum payment. Statement balance. Current balance. Other amount. If you work in financial services, those terms probably feel obvious. If you’re a normal person trying to pay your credit card bill, maybe not. This is one of my favorite fintech examples of something that makes complete sense to the people who built it and considerably less sense to the person trying to use it. ⁠[Read Why Credit Card Payment Options Confuse Users](https://www.productftw.com/productftw-67-why-credit-card-payment-options-confuse-users/) ## **8\. Product Requirements Document (PRD) Template - ProductFTW #86** I have a lot of opinions about PRDs. After writing about whether PRDs are still relevant, I wanted to create something people could actually use. This post includes my PRD template and explains how I think about documenting requirements without turning the PRD into a giant document nobody wants to read. ⁠[Read the Product Requirements Document Template](https://www.productftw.com/product-requirements-document-template/) ## **9\. Real Life is Full of Edge Cases - ProductFTW #87** We design products around expected behavior and then hand them to real people who immediately do things we didn’t expect. Sometimes those situations are truly rare. Sometimes the thing we called an edge case turns out to happen all the time. This post is about designing for the messiness of real life instead of assuming everyone will use our products exactly the way we imagined. ⁠[Read Real Life is Full of Edge Cases](https://www.productftw.com/real-life-is-full-of-edge-cases-productftw-87/) ## **10\. The Biggest Mistake You Can Make During User Interviews - ProductFTW #81** User interviews are incredibly valuable, but they’re also surprisingly easy to mess up. One of the biggest mistakes is going into an interview trying to validate what you already believe. At that point, you’re not really doing research. You’re looking for evidence that you’re right. Good product discovery requires being genuinely willing to hear an answer you don’t want. ⁠[Read The Biggest Mistake You Can Make During User Interviews](https://www.productftw.com/the-biggest-mistake-you-can-make-during-user-interviews/) ## **Here’s to 100** One hundred issues is a lot of product management. We’ve covered lessons, mistakes, opinions, templates, fintech rabbit holes, and plenty of things we wish someone had told us earlier in our careers. Along the way, ProductFTW has also become a place where we can dig into the messy parts of building products and share what we’re learning as we go. On a personal note, I’ve loved being part of writing it. Some of my favorite posts have come from something I was working through myself, a conversation with another product person, or a question that sent me spiraling. Thank you to everyone who reads ProductFTW, shares a post with a coworker, responds with your own experience, tells us when you disagree, or gives us another product problem to obsess over. See you at #101. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### How to Implement Credit Card Regulatory Changes - ProductFTW #99 URL: https://www.productftw.com/how-to-implement-credit-card-regulatory-changes/ Last updated: 2026-10-01T16:15:06.000Z In 2024, I was in the middle of launching a new credit card when the CFPB decided late fees should be $8\. Which, yes, was only two years ago, even though talking about financial regulation in 2024 already feels like telling a story from another lifetime. At the time, we had a decision to make. The CFPB had finalized the rule, but it hadn’t taken effect yet. It was already being challenged, and there were plenty of questions about what was going to happen. Meanwhile, we were building a credit card that needed a late fee. What were we supposed to build? I remember looking around at what other companies were doing and seeing some of them start changing their late fees before they were required to. Do we change ours too? Do we wait? What happens if we build for $8 and the rule never takes effect? Spoiler: it didn’t. The CFPB finalized the rule in March 2024, and it would have created an $8 late fee safe harbor for larger card issuers, which it defined as issuers with more than 1 million open credit card accounts. The rule was challenged, never took effect, and was eventually vacated in 2025\. Then, in 2026, the Senate introduced legislation that would put an $8 cap into law. What happens next? Who knows. This is #8 in the [Consumer Credit is Challenging](https://www.productftw.com/consumer-credit-is-challenging/) series: the rules can change under you after you’ve already built for them. I think there is another lesson here for product managers, though: sometimes the rules haven’t changed yet, and you still have to decide what you’re going to do. When a regulation is proposed or finalized, there can be this weird period where you know something might change, but you aren’t necessarily required to do anything yet. You can wait until you are forced to make the change, make it early, or decide that you like where the regulation is headed and make the change regardless of what ultimately happens. The thing to remember is that making the change early can also be a signal. Whether you intend it to or not, you may be telling your customers and the market where your company stands on the policy. My personal product-management rule is that if I am working at a fintech, especially one launching a new product, I probably don’t need to be the company making that statement. If we aren’t one of the major players shaping the market, I would rather understand what is happening, figure out what our obligations are, get ready for the change, and implement it when we need to. There are absolutely reasons a company might choose differently, but generally I don’t think a fintech needs to volunteer to be the test case. ![Infographic showing a credit card late fee changing from $27 to $8 and the resulting updates across compliance, finance, disclosures, customer communications, engineering, statements, testing, and versioning.](https://www.productftw.com/content/images/2026/09/productftw99.jpg) Just update the fee. Easy. Once you have to implement the regulation, I follow a pretty standard playbook. First, I get everyone in a room. Product, legal, compliance, engineering, operations, finance, and whatever partner actually controls the affected part of the product all need to understand what is changing. Finance matters because a regulatory change can completely change the product's economics. If late fees are going from $30 or $40 to $8, what does that do to the model? How much revenue goes away? Does that change the economics enough that we need to rethink something else about the product? I want finance to rerun the model so we understand the business impact of the change, not just the work required to implement it. Legal and compliance need to interpret the rule. Who does it apply to? When does it take effect? Does it apply to existing customers, new customers, or both? What needs to change in the cardholder agreement? What disclosures need to change? Do we need to notify existing customers? How much notice do we need to give them? It is really easy as a product person to think, “We changed the terms, we’ll just tell the customer,” but credit doesn’t really work like that. Regulation Z has specific requirements around changes to credit card account terms. Certain significant changes generally require written notice at least 45 days before the change becomes effective, although there are exceptions and not every change is treated the same way. A decrease in a fee, for example, isn’t necessarily treated the same way as an increase. This is why I am not making that determination as the product manager. Legal and compliance are going to tell me what we are required to do, and then I am going to make sure the product can actually do it. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. For something like a late fee, we also need to figure out everywhere that fee exists. It could be in the account-opening disclosures, the cardholder agreement, a change-in-terms notice, the periodic statement, customer support content, and probably a few other places depending on how the product was built. Changing the late fee from one number to another sounds simple until you realize how many places that number lives. Then someone has to change the fee in the system. If you own your ledger and servicing stack, maybe engineering handles it. If you are a fintech sitting on top of a processor or issuing platform, it might be a configuration your partner has to change. Either way, “change the late fee to $8” is not a requirement I would ever hand to engineering. I need to know when it changes, which accounts it applies to, what happens to an account whose billing cycle crosses the effective date, what event determines which fee applies, when the customer needs to have received the new terms, what the statement shows, and what happens if the fee gets assessed and then reversed. Then we need to test all of it. I want to know that the backend charges the correct fee on the correct date and that the statement displays the correct fee. I want to know we aren’t accidentally charging someone under the old terms after the new terms take effect. I also want customer support to know what changed because someone is eventually going to ask why they were charged $8 when they used to be charged something else. Then there is one of my favorite topics: versioning. We have [talked about document versioning before](https://www.productftw.com/productftw-41-managing-the-legal-files/), and regulatory changes are exactly why I care about it so much. If we change the cardholder agreement or disclosures, I want to know which version every customer received and which version applied to that customer at any point in time. If someone calls six months later and says, “You charged me the wrong late fee,” I do not want someone opening whatever version of the cardholder agreement happens to be sitting on our website that day and trying to figure out what the customer should have been charged six months ago. I want to know exactly what that customer saw and what terms applied to them on that date. Your disclosure version, effective date, customer communication, statement, and backend configuration all need to tell the same story. This is the part I think people miss when they talk about regulatory changes. From the outside, the change might look like one sentence that changes one number. Inside the product, that one number can change your economics and touch your legal documents, disclosures, customer communications, statement generation, processor configuration, ledger, support tooling, testing plan, and historical records. In this case, we spent 2024 preparing for a rule that never took effect. It was vacated in 2025, and now, in 2026, lawmakers are trying to bring the $8 cap back through legislation. Maybe it comes back, maybe it doesn’t, or maybe something entirely different replaces it. You can’t control that part, but you can control whether your product is built to respond when the rules change. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### How Credit Card Interest Works (And Why It’s So Hard to Calculate) - ProductFTW #98 URL: https://www.productftw.com/how-credit-card-interest-works/ Last updated: 2026-09-24T16:15:20.000Z Matthew recently kicked off a series called [*Consumer Credit is Challenging*](https://www.productftw.com/consumer-credit-is-challenging/), and #10 was “Calculating Interest Is Hard”. He prefaced it by basically saying that this is the one thing you really cannot get wrong in consumer credit. You can fix a lot of things later. Interest isn't one of them. There are very specific rules around how you calculate it, disclose it, and correct it when something goes wrong. The more I talk to people in fintech, though, the more I realize many of us don’t really understand how credit works. I actually made fun of us for this in a talk earlier this year because fintech employees make terrible testers. We tend to make more money, have better credit, and use financial products differently than the average customer. Many of us have probably never been the typical credit card customer we are building for: someone who carries a balance. If you’re like me, your experience with a credit card is pretty boring. You buy things throughout the month, your statement closes, you pay the statement balance, and you do it again next month. You don’t pay interest because you’re in your grace period. A grace period is the time when you can make purchases without paying interest, as long as you pay your statement balance in full by the due date. Most credit cards have one for purchases, although fun fact, they don’t actually have to. Cash advances are also a different story and generally don’t get one. So let’s say I spend $2,000 this month. My statement closes at $2,000\. I pay $2,000 by the due date. I owe no interest. Yay. That is probably how a lot of people working in fintech experience credit. Now let’s say my statement closes at $2,000 and I only pay $1,000\. I didn’t necessarily miss my payment. I could have made my payment perfectly on time. I just didn’t pay the statement balance in full, which means I have started revolving. This is where things get interesting. ![Credit card account summary showing a $2,000 previous balance, $1,550 in payments and credits, $240 in purchases, and $21.24 in interest charged.](https://www.productftw.com/content/images/2026/09/productftw98.png) Depending on the card's terms, I will most likely lose my grace period. Once I am outside of that grace period, new purchases can start accruing interest from the day I make them. I buy groceries on Tuesday; those groceries can start accruing interest on Tuesday. I get gas on Friday; that can start accruing interest on Friday. I make a payment the next Wednesday, and now that payment changes the balance I am accruing interest on. So when we say we’re “calculating interest,” we’re not just taking the balance on someone’s statement and multiplying it by their APR. Many issuers use a daily periodic rate and average daily balance. That means the rate is divided by 360, 365, or 366, depending on the business decision. For example, if my APR is 24.99%, my daily periodic rate is roughly 24.99% divided by 365, or 0.0685% per day. Now I need to know what balance that rate applies to every day. Purchases are adding to it. Payments are reducing it. Credits are reducing it. I might have a cash advance sitting over here at a different APR. Maybe I have a balance transfer over there. Maybe I have a promotional rate on another balance. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Let’s make that real with an overly simple example. Credit card billing cycles are generally around a month, but they aren’t always exactly 30 days. Depending on where the statement dates fall, a cycle might be 28, 29, 30, or 31 days. To keep the math simple, let’s use 30. Going back to my $2,000 statement, I paid $1,000 on time, which means I start the next cycle with $1,000 accruing interest at a 24.99% APR. Here's how my balance changes during the cycle: - My balance stays at $1,000 for the first 20 days. - On day 21, I buy $180 in groceries, and my balance is $1,180 for 3 days. - On day 24, I spend $60 on gas, and my balance is $1,240 for 3 days. - On day 27, a $50 refund posts, and my balance is $1,190 for 2 days. - On day 29, I make a $500 payment, and my balance is $690 for the last 2 days. That gives me an average daily balance of $1,034\. I multiply that by my daily periodic rate of 0.0685% and then by 30 days, which gets me to about $21.24 in interest. Now imagine I’m using the card every day, making payments, getting refunds, and potentially carrying different balances at different APRs. This gets complicated pretty quickly. Then the APR itself can (and will) change. Many credit cards have a variable APR based on an index, such as the U.S. Prime Rate published in The Wall Street Journal, plus a margin. Maybe my rate is Prime + 18.24%. When Prime changes, my APR can change too. Exactly when that happens depends on the cardholder agreement. Now I don’t just need to know what balance I had every day. I also need to know what APR applied to that balance at that point in time. Then someone disputes something. This is one of my favorite examples because the CFPB gives us a very simple one. A customer gets a $300 statement and disputes a $2 transaction. They pay the other $298 within the grace period while the $2 is being investigated. You cannot look at that customer and say, “Well, technically you didn’t pay your $300 statement balance in full, so now you’ve lost your grace period.” Regulation Z allows the customer to withhold that disputed $2 and the related finance charges while the issuer investigates. Doing that cannot cause them to lose the grace period on the undisputed balance. Now let’s say we investigate and determine that the $2 transaction actually was a billing error. We don’t just fix the $2\. We also have to correct related finance or other charges, as applicable. This is where you start to realize how connected it all is. Your dispute system can’t just know that you won or lost a dispute. Your ledger can’t just know that $2 came off the account. Your interest engine can’t just calculate interest every night without understanding what else is happening to that balance. Something that happened to one transaction can change what the customer should have owed somewhere else. Refunds get weird too, although in a slightly different way. Let’s say I buy something and then return it. A normal merchant refund doesn’t necessarily mean we go back in time and pretend the purchase never happened. Generally, the credit impacts the balance when it posts based on the issuer’s balance calculation method. That differs from determining a billing error and needing to correct related finance charges. To the customer, those two things look almost identical. “I spent $50, and then I got my $50 back.” To the system calculating interest, they are not necessarily the same thing. Then there is getting your grace period back, which I also think most of us assume is simpler than it is. You will sometimes hear that you just need to pay your card down to zero and then your grace period resets. That isn’t a universal rule. How you regain the grace period depends on the cardholder agreement, and some terms can require you to pay in full for one or more billing cycles before you get it back. This is why I think “calculating interest is hard” undersells it a little bit. The actual math isn’t that hard. I can divide 24.99% by 365. The hard part is knowing what balance I am calculating interest on, what rate applies to it, whether the customer has a grace period, what happened to that balance yesterday, whether they made a payment today, whether part of it is disputed, whether a credit posted, whether something needs to be corrected retroactively, and what all of that means for tomorrow. Meanwhile, the customer opens their statement, sees $21.24 in interest, and asks why. You need to know exactly why. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Non-Functional Requirements - ProductFTW #97 URL: https://www.productftw.com/non-functional-requirements/ Last updated: 2026-09-17T19:43:53.000Z At Totavi, we work on a lot of innovative projects. Currently, the team and I are building an activation experience for a new wearable payment product and recently completed our first end-to-end test. Seeing the full flow reminded me how much of the customer experience sits outside the basic functional requirements, and that felt worth talking about here. The core activation flow worked. I received the wearable, enabled it, and the confirmation text was sent through. I love the first end-to-end tests because they give us something we hadn’t had before: real timing data. On paper, the first test was successful, but as a user, I noticed a delay in receiving the activation confirmation. This, of course, led to a conversation between product and engineering about timing – a conversation we have often at Totavi and even in [CardsFTW](https://www.cardsftw.com/instant-card-payments-arent-instant/?ref=productftw.com). The discussion centered on a few questions: How long is an acceptable wait? Which systems contributed to the delay? What should the user see while activation is being processed in a UI we don’t control? How would we identify the source if a future activation took longer? The original functional requirement was straightforward: A user can activate their payment wearable. That requirement gave us enough direction to build and test the first version. The first test gave us the data we needed to evaluate and sharpen the non-functional requirements around timing, customer communication, and system coordination. These are the kinds of requirements we don’t spend enough time talking about. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **What is a non-functional requirement?** I don’t love the term *non-functional requirement*. It sounds like a requirement for something that doesn’t function. Functional requirements describe the product’s capabilities. Non-functional requirements set expectations for qualities such as performance, reliability, usability, security, and operability. The functional requirement for our activation flow explained the capability: A user can activate their payment wearable. The related non-functional requirements describe the expected quality of the experience: - The product must reflect a successful activation within an agreed period after the activation partner confirms it. - If activation is still pending, the product must tell the user that processing is continuing. - Receiving the same activation result more than once must not create duplicate status changes or confirmation messages. - The system must record enough timing information to identify where an activation delay occurred. ![Graphic comparing a functional requirement, “It works,” with a non-functional requirement, “It works well,” meaning the product is fast, clear, and dependable.](https://www.productftw.com/content/images/2026/09/nfr-image.png) ## **Define early, validate with real data** Non-functional requirements should be part of the conversation before development begins. Product and engineering should discuss performance, reliability, error handling, customer communication, permissions, and monitoring alongside the functional requirements. You may not have every target in the beginning. Integrations are a good example of where you may need to start with some assumptions and then fill in the gaps as you go. In our wearable test, the partner documentation didn't describe every operational detail that would affect the customer experience, including how often updated card status would become available. That is where testing comes in. We did not need the test to tell us that timing mattered. We needed it to show us how the connected systems behaved under normal conditions so we could replace an initial assumption with a measurable expectation. ## **Turning observations into requirements** The activation test highlights several different types of non-functional requirements: | What we observed | Possible requirement | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Confirmation took longer than expected. | The product must reflect a successful activation within the agreed target after partner confirmation. | | Two processes could report the same activation. | The system must process the activation once and send no more than one confirmation. | | The customer had no clear status while waiting. | While activation is pending, the product must explain that processing is continuing. | | The team needs to identify where time was spent. | Record when activation was submitted, confirmed by the partner, detected by the product, and communicated to the customer. | | The mobile keyboard changed the layout during the flow. | On supported mobile browsers, opening and closing the keyboard must not make the primary action inaccessible. | | OTP behavior depended on the device and browser. | Passcode fields must support autofill, paste, and logical focus order on supported devices. | The exact targets still require decisions. “Within the agreed target” wouldn't actually be in your PRD. In our case, our product and engineering discussion focused on choosing a timing that reflects customer expectations while balancing technical constraints and cost. ## **The happy path is a starting point** Most of our product requirements focus on the ideal sequence: 1. The user starts activation. 2. The partner platform activates the wearable. 3. Our product receives the updated status. 4. The user receives confirmation. The complete flow has more moving parts, especially when integrating with an external partner or multiple partners. The partner platform may make status updates available on its own schedule. Our system may also check periodically for the new status. Those updates could arrive at nearly the same time. One part of the system might know that activation is complete before another does. The happy path tells us what needs to happen. It doesn’t tell us how quickly, reliably, or clearly it needs to happen. Looking at what happens within and between each step helps us identify the non-functional requirements that shape the customer’s experience. ## **What the product manager owns** Product managers don’t need to design the status-checking job or decide how to prevent two processes from updating the same record. We do need to expose the questions hiding behind the happy path: - How long might the customer wait? - What happens if the same result arrives twice? - What does the customer see while the answer is unknown? - How will support investigate a problem? - Which assumptions can only be tested once the systems are connected? Bring those questions to engineering and the relevant partners. Record the decisions in language the team can test. The activation flow worked. The first end-to-end test did exactly what an early test should do: it showed us what we needed to measure and decide before putting the experience in front of customers. We should be thinking about non-functional requirements from the start, even if some targets are still assumptions. Testing helps us confirm them and see how the whole experience comes together. Customers will never know how many systems are involved. They will simply know whether the product feels fast, clear, and dependable. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Consumer Credit is Challenging - ProductFTW #96 URL: https://www.productftw.com/consumer-credit-is-challenging/ Last updated: 2026-09-10T17:09:49.000Z We think about product in the very broad sense: product managers are responsible for everything in and around their product. As a team, we help build, launch, and manage five or six credit products each year. Consumer revolving credit is one of the most complex financial technology products. We’ll dig into each of these more in future posts, but first we wanted to highlight a few of the top reasons why building credit card products is so hard. ![Illustration of an iceberg topped by an orange credit card, with ten labeled sections below the water showing underwriting, APR, interchange, regulation, fair lending, delinquency, funding, changing rules, separate fraud and credit risk, and interest calculations.](https://www.productftw.com/content/images/2026/09/credit-card-iceberg.png) Simple, right? ## 1\. Underwriting is a multi-step process with many variables I wrote about underwriting over on CardsFTW ([Underwriting is More Than Your Score - CardsFTW #210](https://www.cardsftw.com/underwriting-is-more-than-your-score-cardsftw-210/?ref=productftw.com)), so you can check that out for more detail. In short, though, while many people think of underwriting as simply “is my score good enough?” there are many factors. At the start are knock-out rules, such as minimum score thresholds, but there can be knockouts on a dozen or more separate credit factors, such as income, DTI, history length, tradeline counts, delinquency recency, inquiry counts, and utilization. We also have to calculate the right credit APR band, credit limit, the impact of the new credit we offer, and bank-specific preferences. Plus, people’s credit files are weird, so there are inevitably edge cases and strange results to adjust. ## 2\. The posted APR is not what the business actually earns, and it's not what most cardholders actually pay Good product managers know how their product generates revenue and profit. It’s easy to think that if you charge 24.99% in your middle band, then you’ll probably make 24.99%. It's never this simple. Subprime cardholders pay interest and fees at higher rates than prime. Weave in introductory balance offers, initial grace periods, payments at various times of the month, and the amount of interest you are earning is usually less than the posted APR. At the same time, the effective cost can be higher for some users. ## 3\. Interchange is not what it seems The headline rate of interchange bites programs early and often. Major merchants may have special programs (ahem, Amazon, Costco). Your users may love mobile wallets more than others. Your users may travel internationally. Each of these causes your interchange to adjust. You can’t ask your bank or network before you launch either. They’ll basically say: it’s a big, complex table; wait and see. Key point: assume it’s worse than your model says. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## 4\. The regulatory stack isn't one law; it’s a bunch of them. Credit programs must keep track of BSA, Reg B, Reg Z, SCRA, MLA, and more. Laws can be unclear, laws can create conflict with each other, and every bank thinks your old bank’s position is absurd. ## 5\. Fair lending complicates even the variables that feel objective Disparate treatment and disparate impact are two distinct risks under ECOA, and a facially neutral variable (alternative cash-flow data, a platform metric) can still fail if it correlates with a protected class without documented justification. The adverse action requirement compounds this: you have to give specific, accurate reasons for a decline, and per CFPB, a complex or black-box model does not excuse a vague reason. So the more sophisticated your underwriting gets, the harder your compliance obligation gets, not easier. 🗽 Note: I know the current administration isn’t into this one, but I think it will come back. ## 6\. Who is delinquent and by how much really matters There’s a simple way to look at this: - Paid on time - Paid late (1-30) - Paid very late (31-180) - Charged off However, you could also split it into likelihood to go delinquent (always pays the minimum), first time you’re late (what’s wrong with a day or two), and awareness that, in some cases, that first late payment leads to a full charge-off. Once you’re past 180 days and in collections, you may get some pennies back on the dollar, and it is all a part of the equation. ## 7\. You need a lot of money to lend Most fintech companies cannot finance the lending of their card program themselves. Think about it this way: 2,000 cardholders spending about 2,000 a month and revolving some of it can require $5-10MM in tied-up capital at a steady run-rate. As a result, fintech card programs need a warehouse lender for most receivables. Early-stage companies often can't get a second lender for that residual piece, so they have to raise equity to lend, not just to run the business. The private credit funds have their own concerns. ## 8\. The rules can change under you after you've already built for them In 2024, the CFPB planned to limit late fees to $8\. In 2025, the rule was vacated. In 2026, Senate democrats tried to introduce it again. What’s next? Who knows? I do know you’re responsible for it. ## 9\. Fraud and credit risk are separate axes, and fraud is oddly hard to benchmark by tier Net fraud losses for prime and super-prime run roughly 5 to 12 basis points of purchase volume, with best-in-class programs at 3 to 5 bps, but public data doesn't segment fraud by FICO band. Even a "simple" question like "what's normal fraud loss for a prime card" takes real digging because the industry doesn't publish it that way. ## 10\. Calculating interest is hard You can’t get this one wrong; it’s against the law to do so. You must calculate it correctly. If a user is revolving but disputes a transaction and then wins, it’s one scenario. They lose; it’s another. They win, but you miscalculated the required payment and charged interest; that’s not good. A lot of companies have recently entered revolving credit and say they know what they are doing, but it’s ultimately a lot more complex than that. You must test and ensure every scenario is run through. ## Next time We’ll dig into each of these in more detail over the coming year. What’s your credit card gotcha you want us to discuss? ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders succeed by offering realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Why Product Managers Need a Decision Log (+ Free Template) - ProductFTW #95 URL: https://www.productftw.com/decision-log-template/ Last updated: 2026-09-03T15:52:10.000Z We’ve talked a lot about how part of the product manager’s role is to translate, document, and communicate all of the things that are happening throughout a project or product lifecycle. You’re pulling together conversations happening across engineering, design, compliance, operations, leadership, vendors, and whoever else is involved so that everyone ultimately understands what we’re doing and why we’re doing it. ![Image of the decision log template](https://www.productftw.com/content/images/2026/09/image.png) A free template for members! That includes keeping track of decisions being made along the way. The problem is, you usually don’t realize you need to document one until you’re already deep into the project and someone asks a question you know you answered three months ago. You vaguely remember the conversation. Someone else remembers it differently. You know there was a reason you landed where you did, but now you’re searching through Slack, meeting notes, and five different documents trying to figure out what happened. This is why, before I start any big project, I like to create a decision log. [Get the Decision Log Template](https://www.productftw.com/templates-product-decision-log/) ## **Create It Before You Need It** A decision log is exactly what it sounds like. It’s one place where you keep track of the decisions made throughout a project's lifecycle, including what you decided, why you decided it, and who was involved. Create it before you actually feel like you need it. If you wait until the project is well underway, you’ll have to go backward and try to remember all of the decisions you’ve already made. Some will be easy to reconstruct, but plenty of others will have happened during a meeting or a quick conversation and will already be lost. I find that a spreadsheet is the easiest way to manage this. It doesn’t need to be a complicated system or another massive piece of product documentation that you have to maintain. It can sit in the background of the project and grow as decisions are made. At first, you’ll probably use it more than you expect, and it might feel overwhelming. That’s when you’ll be making a lot of foundational decisions and figuring out how the product is going to work. As you get further into the project, that starts to slow down, and maintaining the log gets much easier. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **What I Keep in the Log** For every decision, I want enough information that someone who wasn’t in the room could come back later and understand what happened. I want to know what question we were trying to answer, what options we considered, what we ultimately decided, why we made that decision, when we made it, and who was involved. I also want to know who made the decision. There can be a lot of people involved in a conversation without all of those people having the authority to make the final call. You might have Product, Engineering, Compliance, Legal, Operations, and a vendor all contributing information, but ultimately someone needs to own the decision and have the authority to make it. I also link to any relevant documentation, whether that’s a PRD, a ticket, research, meeting notes, designs, vendor documentation, or something else that provides additional context. The decision log doesn’t need to contain every detail of every conversation. It needs to give you enough information to understand what happened, then point you to the deeper context. ## **Your PRD Is Still the Source of Truth** Ultimately, these decisions should be reflected in your product requirements. If you decide that a customer has to do X before they can do Y, the PRD should reflect that. The decision log shouldn’t become a second set of requirements that your team now has to keep in sync. What the decision log gives you is the history behind those requirements. This is especially useful when you’re working on a large initiative because you may have several PRDs. In fintech, I tend to create multiple because a single one can get unruly very quickly. Onboarding might be one PRD, while transaction management is another. Depending on the program, you might also have separate requirements for servicing, rewards, repayment, disputes, or other major components of the experience. The problem is that the decisions you’re making don’t necessarily fit neatly into those same buckets. A decision you make about onboarding might have implications for transaction management. Something Compliance decides might affect three different areas of the product. The decision log can span all those PRDs and give you a single place to understand how you arrived at the current set of requirements. ## **You Still Need to Own the Actual Record** I’ve written recently about one of the [problems with going back and forth with AI over and over again](https://www.productftw.com/prd-ai-prompt/). The longer the conversation goes on and the more information you introduce, the easier it becomes for things to get muddied. AI can start interpreting something differently, combining information that shouldn’t be combined, or giving you an answer that sounds right even though it isn’t actually what you originally decided. I don’t want that happening to the historical record of a project. Keep the actual decision log outside of AI, somewhere you control and can preserve. AI can help you create entries and interact with the information, but you are responsible for ensuring the log is accurate and that new decisions don’t change the history of previous ones. If a decision changes, that’s fine. Decisions change all the time as you learn more. When this happens, create a new decision and link it back to the original rather than rewriting what happened. That way, six months from now, you can see that you originally decided X, what information you had at the time, and why you later changed the decision to Y. ## **Where I Think AI Gets Really Useful** The part of this that I find most useful isn’t having AI format the decisions. It’s being able to chat with the decision log once it starts getting really, really long. Before I start another conversation, I want to be able to ask, “Have we made this decision yet?” I want AI to tell me yes or no and, if we have, show me the decision, why we made it, and anything else in the log that seems similar or related. That is incredibly valuable on a project that has been going on for six months or a year. You won’t remember every decision that was made, and you won’t remember every conversation that led to those decisions. Someone new joining the project certainly won’t either. AI can also help with broader questions. What decisions have we made about onboarding? Have we made any that affect this requirement? Why did we decide not to support this? Was Compliance involved in this decision? Have we talked about something similar before? The important distinction is that AI is searching and helping you understand a record that you own. It isn’t becoming the record itself. 🖇️ Check out our decision log template [here](https://www.productftw.com/product-decision-log-template/). ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Card Onboarding Requirements: Field Validations and Error States - ProductFTW #94 URL: https://www.productftw.com/card-onboarding-requirements-field-validations-and-error-states-productftw-94/ Last updated: 2026-08-27T16:15:05.000Z As a product consultant who primarily works in fintech, I’ve implemented many card onboarding flows: debit and credit, with a variety of banks, processors, and KYC providers, built with very different software stacks. No matter what the program looks like, they all share many of the same basic requirements. What characters should we accept in a name? How should a phone number be formatted? What happens when someone enters a P.O. Box? What happens if a date technically follows the right format but isn’t actually a real date? What should the error say when something goes wrong? None of these decisions are particularly complicated on their own, but there are a lot of them, and I don’t want to define them from scratch every time. If you don’t make these decisions when you’re writing your requirements, someone will have to make them later (or worse, miss them entirely). ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Over time, I’ve built a set of baseline requirements for a new consumer card onboarding flow, and today I’m sharing it. It includes the key fields you need to cover and the exact requirement language I use for each field, so you can copy it into your own requirements and adjust it to your program. Your exact requirements will depend on your program, your bank, your processor, your KYC provider, and any other systems that ultimately need to accept this information. ‼️ These are specifically written around U.S. names, addresses, phone numbers, Social Security numbers, states and territories, ZIP codes, and the other information typically collected during a U.S. card application. If you’re building an international or multi-country onboarding experience, these validations won't work as written. ## **Start With the Card Onboarding Form** Before getting into the individual fields, I usually define how I expect the onboarding form itself to work. All required fields must be completed before the user can progress; the application should be navigable by touch or keyboard; and errors should appear after the user interacts with a field or attempts to submit the page. If there are unresolved errors, those fields should be visually highlighted so the user knows which fields need to be fixed. I also define any formatting that should happen as the user types. If I want the phone number displayed as (XXX) XXX-XXXX, the date of birth displayed as MM/DD/YYYY, or the SSN displayed as XXX-XX-XXXX, I write that into the requirements rather than assuming it will be inferred from the design. There are also requirements that have nothing to do with what the customer sees. For example, I may need to capture the user’s IP address and submit it with the application. I include those in the same requirements because they’re still part of the information we need to successfully submit the application. ![Mock card onboarding form showing personal information fields with validation errors for email, phone number, city, state, ZIP code, date of birth, and SSN.](https://www.productftw.com/content/images/2026/08/application.jpg) Proof that AI ignores requirements: I gave it the field list, but it still displayed the IP address. ### **Requirements** > All required fields must be completed before the user can progress to the next screen. The application must support navigation by touch and keyboard. Validation errors should appear after field interaction or page submission, rather than before the user interacts with the field. The user must not be able to progress while required fields are incomplete or validation errors remain unresolved. Fields with unresolved errors must be visually highlighted. Inputs should automatically format as specified for each field. ## **First Name** For first name, I require at least one character and allow up to 40\. I allow uppercase and lowercase letters, apostrophes, hyphens, and single spaces between name parts. That supports names like O’Brien or Mary Jane without opening the field up to digits or unrelated special characters. I don’t allow leading or trailing spaces, and I also explicitly account for entries that technically use allowed characters but aren’t actually names. An entry that consists entirely of spaces or hyphens shouldn’t pass validation just because those characters are allowed within a valid name. ### **Requirements** > Required. Must contain 1 to 40 characters. May include uppercase and lowercase letters (A-Z, a-z), apostrophes, hyphens, and single spaces between name parts. Must not include digits or other special characters. Must not allow leading or trailing spaces. Must not allow input consisting only of spaces or hyphens. ## **Last Name** I treat last name similarly. It is required to be between 1 and 40 characters and accepts letters, apostrophes, hyphens, and single spaces between name parts. Again, I don’t allow digits or other special characters, leading or trailing spaces, or an entry made up entirely of spaces or hyphens. ### **Requirements** > Required. Must contain 1 to 40 characters. May include uppercase and lowercase letters (A-Z, a-z), apostrophes, hyphens, and single spaces between name parts. Must not include digits or other special characters. Must not allow leading or trailing spaces. Must not allow input consisting only of spaces or hyphens. ## **Email** Email is required and can be between three and 255 characters. It needs to contain exactly one @, at least one period after the @, and at least two characters before it. Before the @, I allow letters, digits, and characters such as +, ., \_, and -. I also allow subdomains in the domain portion and don’t allow spaces or email addresses that start or end with an @ or a period. _This post is for subscribers only._ ### Why Customer Support Still Matters in the Age of AI - ProductFTW #93 URL: https://www.productftw.com/why-customer-support-still-matters-in-the-age-of-ai/ Last updated: 2026-08-20T16:15:16.000Z I think there are two types of people in this world: people who seek help immediately and people who wait until they absolutely cannot solve the problem themselves. I am firmly in the second group. I don’t go to the doctor every time something feels slightly off. I take my health seriously and know what feels normal for me, so my instinct is usually to wait, pay attention, and see if the problem resolves on its own. If I’m actually seeking immediate medical attention, something is wrong. My best friend is the opposite. If something feels wrong, she wants to address it. She would rather ask the question early, find out it’s nothing, and move on with her life. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. I don’t think either approach is necessarily better. I do think we behave the same way as customers. Some people ask for help the moment they encounter friction. They’ll search the help center, open the chat window, ask the AI assistant, or contact support before spending twenty minutes trying to figure something out themselves. Then there are people like me. By the time I contact customer support, I have tried everything. I have searched your website. I have read your FAQ. I have probably Googled the problem. I have clicked around your account settings looking for the answer. If I am finally trying to speak to a person, I need help. Unfortunately, we’ve spent the last several years making it increasingly difficult to talk to a person. Recently, I bought something online and accidentally ordered too many. I needed to return one, which should have been a pretty straightforward problem. Instead, getting to an actual person felt nearly impossible. Once I was able to reach someone, we talked through what had happened, they fixed the issue, and I walked away happy. What stood out to me wasn’t that I had needed customer support in the first place. It was how dramatically my opinion of the company changed once I finally reached a person. ![ Customer service IVR flowchart showing every support option looping back to automated prompts, with no path to a human agent.](https://www.productftw.com/content/images/2026/08/customer-support-ivr.jpg) Your call is very important to us. Just not important enough to let you talk to anyone. Back in my day, and apparently I am old enough to say that now, you could hit zero on an IVR and you would be forwarded to a person. Today, I find myself doing the digital equivalent: clicking “other,” rephrasing my question for the chatbot, typing “representative,” and occasionally rage-clicking buttons hoping one of them will reveal the secret passage to a human being. I understand why we got here. Most customer questions don’t need a person. If someone wants to know where their order is, reset a password, change their billing information, or understand a basic feature, we should make those things ridiculously easy to do without contacting anyone. AI is going to make self-service even better, and that’s a good thing. The problem is assuming that because most solutions can be automated, every solution should be. For someone like me, the decision to contact support already tells you something. I’ve reached the end of what I’m willing or able to solve myself. Sending me back to an FAQ I’ve already read isn’t making your support operation more efficient. It’s taking a customer who already has a problem and giving them another one. That’s particularly strange when you consider how much effort we put into every other part of the customer journey. As product managers, we obsess over onboarding. We map funnels. We remove friction from checkout. We test copy, buttons, notifications, and empty states. We spend an enormous amount of time thinking about how someone discovers our product, understands it, pays for it, and starts using it. Then they have a problem after they’ve given us their money, and suddenly customer experience becomes someone else’s department. I think that’s a mistake. Customer support is still part of the product. A support interaction is one of the few moments when a customer is explicitly telling you that their experience has broken down. That’s obviously an opportunity to fix the immediate problem, but also to rebuild trust. A frustrating experience can become a surprisingly positive one when someone feels heard, and their problem is actually solved. Amazon has understood some version of this for years. I rarely need to talk to someone to return something because they’ve made the return itself incredibly easy. I don’t have to prove I’m eligible for a refund or navigate an elaborate support flow. The product handles the common case so well that I don’t need support. That’s what good automation should do. It should eliminate the need to ask for help when the problem is simple. It shouldn’t eliminate the ability to ask for help when the problem isn’t. As AI becomes better at handling customer support, I think that distinction is going to matter more, not less. We should be designing incredible self-service experiences for customers who want an immediate answer. Give them good documentation, intuitive workflows, useful AI, and ways to solve common problems without waiting for anyone. Then pay attention when someone is still asking for help. That person might not be failing to use your chatbot correctly. They might be telling you that their problem doesn’t fit neatly into the options you’ve given them. If you’ve spent the entire customer journey trying to delight someone enough to become a customer, don’t stop designing the experience once they need your help. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### The Skills AI Can’t Learn for You - ProductFTW #92 URL: https://www.productftw.com/the-skills-ai-cant-learn-for-you/ Last updated: 2026-08-13T16:25:32.000Z On the drive from the airport to fintech\_devcon, Matthew asked me a question that caught me off guard. “Do you think I push you too hard?” My answer was immediate. “No.” The more I thought about it over the next few hours, the more I realized it wasn’t because he doesn’t challenge me. It’s because I don’t think that’s the problem anymore. As adults, we actually have the opposite problem. Nobody pushes us. When we’re younger, growth is built into life. School forces us to give presentations, work with people we didn’t choose, learn subjects we’ve never thought about, and constantly do things for the first time. Then we graduate, settle into careers, and eventually become good at what we do. If we’re lucky, we work with people who challenge us, but it’s surprisingly easy to spend years getting better at the same things without ever stepping outside our comfort zone. I think product management is especially susceptible to this. We naturally become better at prioritization, stakeholder management, discovery, strategy, and execution because we practice those skills every day. That’s exactly what our jobs require. The downside is that we can mistake becoming more efficient for actually growing. Some of the most valuable skills in our careers–public speaking, writing, networking, telling a compelling story, and making difficult decisions–only improve when we intentionally put ourselves in situations that feel uncomfortable. ![Ellen (author) presenting to an audience during a Fintech DevCon conference session.](https://www.productftw.com/content/images/2026/08/fintech_devcon.jpeg) Me, voluntarily choosing friction and immediately regretting it. Fintech\_devcon was my first solo speaker session. I had moderated panels before, but I was never at the center of the stage, sharing my experience, and that made me incredibly uncomfortable. When something is hard for me, I find it nearly impossible to dedicate time and effort to it. I want to run away from it. I will find 12 other things that suddenly seem more important and move it to the bottom of my to-do list until I absolutely cannot avoid it any longer. Preparing for this talk was no different. AI is now good enough that when something is hard, you can avoid a lot of the tough parts and have it do the work for you. In truth, that’s exactly what I tried to do. I had AI help build my outline, turn it into slides, write speaker notes, and piece together the story I wanted to tell. I ended up with something that looked like a finished presentation, but I quickly realized I had let AI jumble up the entire point of my talk. I couldn’t remember why I was telling certain stories, I wasn’t retaining the material, and the presentation no longer felt like something I actually knew how to give, and it lacked authenticity. What AI couldn’t do was turn my experience into a story that felt like mine. It could organize the material, but it couldn’t decide what mattered to me, make the story flow in a way that felt natural when I told it, or help me internalize it well enough to stand in front of a crowd without constantly trying to remember what came next. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. At some point, I had to stop fighting with a prompt window and start using my brain. I had to decide what I actually believed, which stories were worth telling, and how I wanted people to feel when they left the room. Those decisions had to come from me, not AI. As product managers, we’re going to keep finding new ways to use AI. It will help us write PRDs, summarize research, analyze customer feedback, create presentations, and probably do things we haven’t imagined yet. We should absolutely embrace it. The mistake would be outsourcing the parts of the work that actually teach us something. Producing better artifacts isn’t the same as becoming a better product manager. A lot of what makes us better product managers doesn’t produce an artifact at all. It comes from talking to people, putting ourselves in unfamiliar situations, and being exposed to ideas we wouldn’t have found on our own. I felt that throughout the conference, especially when it came to networking. It was easy when I was surrounded by my coworkers, but when I wasn’t, I had to put myself out there. At one point, that meant walking up to a group of strangers and asking if I could eat dinner with them. AI could have identified everyone at the table and given me talking points, but it never could have predicted the conversations we’d have throughout the night. None of them would have happened if I hadn’t walked up to the table in the first place. It was another small reminder that the uncomfortable part was also the part that made the experience worthwhile. By the time I got home, I was still thinking about the question Matthew asked me on the drive there. I don’t think he pushes me "too hard". I’m realizing that I need people who push me, and I need to keep finding opportunities to push myself. As product managers, we’re trained to look for friction and remove it. AI is making us incredibly good at doing the same thing in our own work, and most of the time, that’s exactly what I want it to do. I don’t need to grow from every tedious task on my to-do list, but as we get better at removing friction from our work, I think we also need to get better at intentionally adding some of it back into our lives. Sometimes something is hard because it’s tedious. Other times, it’s hard because we haven’t learned how to do it yet. If we use AI to avoid both, we also avoid the discomfort of learning something new. Giving a solo talk was hard for me. Walking up to a table of strangers was hard for me. I could have made both experiences easier, or avoided them altogether, but that would have missed the point. The friction was where I actually grew. I don’t want to become so good at removing friction that I also remove the experiences that make me better. AI can make the work easier, but it can’t do the growing for me. Those are the skills AI can’t learn for you. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Is the Product Manager the CEO of the Product? - ProductFTW #91 URL: https://www.productftw.com/is-the-product-manager-the-ceo-of-the-product/ Last updated: 2026-07-30T16:15:37.000Z ## Programming Note The Totavi product and engineering team will be at Fintech Devcon next week. We hope to see some of you there, especially for [Ellen's talk on instant payments](https://fintechdevcon.io/speakers/ellen-dearborn/?ref=productftw.com). We'll be taking next week off due to travel and will be back the following week. ## Product Manager Responsibilities and Accountability A couple of weeks ago, Zach wrote [*From Product Tripod to Pogo Stick*](https://www.productftw.com/from-product-tripod-to-pogo-stick/) about how AI is changing the traditional relationship between product, design, and engineering. His argument was that AI is making each discipline more capable on its own, allowing individuals to do work that previously required another member of the team. I think he's largely right. Product managers can generate prototypes in minutes. Engineers can create UI mockups without opening a design tool. Designers can build working applications instead of static concepts. The lines between roles are becoming less rigid than they were even a few years ago. That discussion got me thinking about another phrase that has been repeated for years: that the product manager is the "CEO of the product." I've worked as both a product manager and a CEO over the past twenty years, and I've never been particularly fond of the comparison. I talked about this a bit last year during our [Product Talks series](https://www.productftw.com/productftw-50-product-talks-with-matthew-goldman/). The analogy sounds good, but it falls apart once you think about what CEOs are actually responsible for. ![Product management meme showing a contrast between the perception of a product manager as the powerful “CEO of the product” and the reality of creating Jira tickets, highlighting the gap between product leadership expectations and daily responsibilities.](https://www.productftw.com/content/images/2026/07/product-ceo.png) When they hire you to be the “CEO of the product” but forget to give you CEO powers. A CEO hires executives, raises capital, makes payroll, sets company strategy, approves budgets, manages a board, and ultimately carries responsibility for the success or failure of an entire business. Product managers don't have those responsibilities, nor do they have the authority that comes with them. Most PMs cannot hire or fire members of their team, decide how much engineering capacity they receive, or control the marketing budget. Only some organizations give product managers direct profit and loss responsibility. Calling a PM the CEO of the product makes for a catchy conference talk, but it isn't an accurate description of the job. Where the comparison starts to become useful is accountability. While product managers don't have the authority of a CEO, they are often held accountable for whether a product succeeds. That accountability extends well beyond writing requirements or prioritizing a backlog. A product manager is responsible for understanding the customer, defining the problem, deciding what should be built, and making sure the organization stays focused on solving the right problem. None of those responsibilities have changed because AI became better at writing code. I also don't believe AI changes the division of responsibilities between product and engineering. Product managers should continue to own the problem, not the implementation. Engineering leaders should continue to own architecture, technical design, scalability, and maintainability. AI can certainly generate architectural recommendations, but I'd still rather have an experienced engineering lead evaluate those recommendations than have a product manager pretend to be a software architect. Good product managers understand technology well enough to ask the right questions and recognize tradeoffs, but they don't need to become the best engineer in the room. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. One area where I've consistently disagreed with many organizations is project management. Plenty of companies introduce project managers or scrum masters to keep everyone organized and moving in the same direction. I've worked with some outstanding people in both roles, but I've never been convinced that delivery should be separated from product management. Being a product manager is already a difficult job, but I don't think that difficulty is a good reason to split accountability across multiple people. The reality is that product managers are delivery managers whether they want to be or not. They need to know whether engineering is on schedule, whether legal has reviewed the customer agreement, whether marketing is ready for launch, whether customer support has completed training, and whether operations can actually support the product that is about to ship. Even if someone else is responsible for tracking all of those workstreams, the product manager still has to understand them. They still need the information in order to make decisions. Adding another layer between the PM and the rest of the organization often means information arrives later, context gets filtered, and decisions take longer. The PM still owns the outcome, but now someone else owns the status updates. Another area that often gets overlooked is financial understanding. Every meaningful product decision has an economic consequence, whether it's obvious or not. Pricing changes affect adoption. Reward structures affect profitability. Underwriting changes affect losses. Operational improvements reduce servicing costs. Feature prioritization determines where engineering resources are invested and, ultimately, where the business expects to generate returns. If a product manager doesn't understand those relationships, it's very difficult to make good trade-off decisions. That doesn't mean every PM needs to become a finance expert or build three-statement financial models from scratch. Many organizations have excellent finance and FP&A teams that provide those capabilities. But product managers should absolutely understand how their product makes money, where it loses money, what assumptions drive profitability, and how individual decisions impact the economics of the business. Without that understanding, product prioritization becomes an exercise in opinions rather than informed decision-making. Perhaps that's why the role has always felt so demanding. Product managers spend their days talking to customers, writing requirements, reviewing designs, answering engineering questions, coordinating launches, working with legal, discussing marketing plans, analyzing data, understanding financial performance, and making hundreds of small trade-off decisions that collectively determine whether a product succeeds. AI will make many of those individual activities faster, but it doesn't remove responsibility for making the right decisions. If anything, faster execution simply means those decisions come more quickly and with greater frequency. Years ago, a product manager who worked for me looked up after another long day and simply said, "This is a hard job." He was right then, and I think he's still right today. 🖇️ Did someone forward this to you? [Subscribe to ProductFTW today.](https://www.productftw.com/) ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### When Should Repayment Emails Be Sent? - ProductFTW #90 URL: https://www.productftw.com/when-should-repayment-emails-be-sent/ Last updated: 2026-07-28T00:20:02.000Z I’m currently preparing for my DevCon presentation, [The Hidden Cost of “Instant”: Timing Decisions in Card Payments and Rewards](https://fintechdevcon.io/speakers/ellen-dearborn/?ref=productftw.com). As I’ve been working through the presentation, I’ve found myself revisiting a lot of the product decisions I’ve had to make over the years around repayment and rewards. There were far more topics than I could possibly fit into a 45-minute session. One that stood out because it ended up being much more complicated than I expected was repayment emails. ![Side-by-side examples of three credit card repayment transactional emails. The first is an American Express payment reminder showing the statement balance, minimum payment due, payment due date, and buttons to view the statement or make a payment. The second is a Chase payment scheduled confirmation displaying the payment amount and effective date. The third is an Apple Card payment confirmation stating that a payment has been received and applied to the account. The three examples illustrate different types of repayment communications discussed in the article.](https://www.productftw.com/content/images/2026/07/payment-emails.png) Product requirement: “Send a repayment email.” Product reality: …which one? 😅 At first, it sounds like a simple requirement: “Send a reminder before the payment is due.” The deeper you get into implementation, though, the more questions you uncover. Before long, that single requirement turns into dozens of product decisions that affect engineering, customer experience, support, compliance, and operations. ‼️ Before I go any further, I have to include my standard disclaimer. I’m not a lawyer, a compliance officer, or your friendly neighborhood regulatory expert. I seem to have to include that disclaimer every time I write about payments, so I’m making it official. If your compliance team is reading this, I promise I’m sending people your way before anyone launches anything. Once you start thinking about reminders, confirmations, and other transactional communications, the questions multiply quickly. Once a payment becomes delinquent, you’re entering the world of collections, which is a whole different can of worms that deserves its own article. That’s where product teams have to decide not only when to communicate, but also whether a communication should be sent at all. The first question every product team has to answer is the same one that inspired this article. When should a repayment email be sent? Should it be seven days before the due date? Three days? The morning it’s due? All three? There isn’t a universally correct answer because every product, customer base, and servicing strategy is different. What matters is that you make the decision intentionally. Of course, deciding *when* to send a reminder is only the beginning. Consider just a few common scenarios: - The customer already made a manual payment. - The customer only paid the minimum payment. - The customer made a partial payment. - The customer scheduled a payment that hasn’t processed yet. - AutoPay is enabled. - The payment ultimately fails. None of those scenarios showed up in the original requirement, but they all influence whether a reminder should be sent and what it should say. As I worked through these scenarios, I realized repayment reminder emails shouldn’t be driven by dates alone. They should be driven by the customer’s current state. Before sending any communication, I’d want to know: - Has the customer already made a payment? - Was the payment successful? - Is a payment already scheduled? - Is AutoPay enabled? - Has the payment failed? - Is there still an action the customer needs to take? The answers determine both whether an email should be sent and what information it should contain. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. That leads to another product decision: What information should you actually include in the email? Personally, I lean toward giving customers as much useful information as possible. If I’m opening a payment reminder, I’d rather immediately see my due date, minimum payment, statement balance, and anything else I need instead of being told to log into the application. Some issuers allow consumers to opt in or out of this information via email. Often missed is the requirement to make it clear what card is being referenced: larger issuers may frequently have users with more than one card. The challenge is that more information also creates more opportunities for inconsistency. If the customer makes a payment after the email is generated but before it’s opened, or if the wrong balance is referenced, the email immediately becomes a source of confusion. That’s one reason many issuers intentionally keep repayment emails relatively lightweight and direct customers back to the application for the most current information. At this point, I stopped thinking about repayment emails as individual notifications and started thinking about them as a communication strategy. The question was no longer, “When should we send a reminder?” It became, “What communications should exist, and what rules determine whether each one is sent?” The first thing I’d do as a product manager is work with compliance to identify the communications we actually want to support. Depending on your product, that list could include something like: - Statement available - Payment reminders - Payment confirmations - Payment issues (failed, reversed, returned, etc.) - Payment overdue notifications Once you know which communications you want to support, each one needs a clear set of product requirements. Some of the questions I use: - What business event triggers the communication? - When should it be sent? - When should it not be sent? - Does the messaging change based on the customer’s account state? - What information should be included? - How do you ensure the information is accurate when the customer reads it? - How do you prevent duplicate communications? - Should this also be delivered through other channels like push notifications or SMS? By the time I finished making that list, I realized the original requirement, “Send a repayment reminder email,” wasn’t really a requirement at all. It was the title of an entire feature. That’s one of the things I enjoy most about product management. Features almost always look simple at first. The real work is uncovering all of the decisions hiding underneath them. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. 202607 ### From Product Tripod to Pogo Stick - ProductFTW #89 URL: https://www.productftw.com/from-product-tripod-to-pogo-stick/ Last updated: 2026-07-16T16:15:46.000Z I've been the whole product team before. The org chart said product manager, but what I actually did was… a lot more: I wrote the spec, mocked up screens because we didn't have a designer, wrote the backend business logic, and created the SQL reports myself because asking eng was a sprint-and-a-half of work. If you’ve worked at a startup, I’m sure this sounds familiar because you've lived it. Last month, big tech made this dynamic official. [Coinbase announced it was cutting 14%](https://finance.yahoo.com/markets/crypto/article/coinbase-to-lay-off-700-workers-as-ceo-brian-armstrong-restructures-crypto-exchange-for-ai-efficiency-114736268.html?ref=productftw.com) of its staff and introducing one-person teams: a single person acting as engineer, designer, and product manager, backed by AI. Then, Block cut 40% of its roles while their CEO [published a piece](https://block.xyz/inside/from-hierarchy-to-intelligence?ref=productftw.com) questioning whether companies need human hierarchy at all. Now, LinkedIn has converted its Associate Product Manager program into a "[Product Builder](https://www.linkedin.com/posts/tomercohen%5Fa-few-months-ago-a-mom-of-two-college-students-activity-7366127683346358272-JxnC?ref=productftw.com)" program that trains new hires across product, design, and engineering simultaneously. That accidental one-person team is becoming deliberate org design, and with it, the product tripod is collapsing into a single role. ![A man with an intentionally pasted-on face jumps on a white pogo stick above a park.](https://www.productftw.com/content/images/2026/07/pogo-face-4x5.jpg) That's totally me guys. ## **Why the tripod existed in the first place** The classic product team is a tripod: a PM, a designer, and an engineering team, each a leg holding up the work. The tripod existed because each leg was a discipline that took a career to build. PMs held the business context and served as the customer's voice. Engineers held the tech. Designers held the craft of making software usable. Building good products required all three, and no single person could hold all three at professional depth. So we split them across people and paid the coordination tax, the PRDs and handoffs and sprint planning, as the cost of doing business. This paradigm held for decades because the constraint was that expertise was expensive to acquire and impossible to fake. Now, AI has broken the constraint, but not the disciplines themselves. ## **The case for the pogo stick** Whichever leg of the tripod you started on, the distance to the other two has collapsed. An engineer can now get to credible design and decent customer synthesis in months instead of years. A designer can direct an implementation they couldn't have written themselves. The three disciplines still exist, and you still need all three to build good products, they just don’t require three bodies. A skilled person with AI tooling ships with a speed and coherence the traditional three-way team can't match. There's no handoff loss. There's no design-by-committee sanding the edges off a good idea. The vision in your head is the vision you ship. A competent builder can go from idea to design to code to prod in days, sometimes hours, at quality that would have taken a full team a quarter to reach. The people who develop competency across all three legs are going to thrive. The specialists who refuse to develop the other two won't have a role to hide in much longer. So, the tripod is becoming a pogo stick, with one point of contact with the ground. It's much faster, much more maneuverable, and requires constant balance from the person on it. ## **What the tripod was actually doing** The pogo stick is going to get more common, but I don't think it's the end state, and at scaled companies it may never be the right answer. The tripod is doing something that’s easy to take for granted. Each leg held a load-bearing competency, and competent peers raised each other's floor. The designer says "I watched three users miss that button." The engineer says, "that's three months for an edge case, let’s do something different." Every bad idea I've shipped got worse in isolation, and every good one got sharper because someone I respected pushed back before a customer ever saw it. Your AI replaces none of this because it's the most agreeable "peer" you'll ever have. It optimizes for your satisfaction, not the product's quality. It never quits in protest, never sighs in a design review, never tells you your feature idea sucks. It will build the wrong thing beautifully, at scale, on demand. That changes where bad ideas go to die. On a tripod team, they died in review, on Tuesday, for free. On a pogo stick, nothing dies until users ignore it. The feedback loop moves from "a peer catches it this week" to "the metrics catch it next quarter." You ship faster and learn slower. Compound that across a roadmap and you get the thing everyone's started calling slop: high-volume, well-rendered, useless garbage. The artifacts of design and product thinking are all there, but the craft and judgment behind them isn't. So if you're riding the pogo stick, whether by ambition or by layoff, the job is to manufacture the friction you no longer get for free. Prompt your AI to attack your plan before it executes it; make it argue the case against the feature, and make yourself respond. Recruit one human who sees the work before it ships: a customer, an advisor, your cofounder, anyone whose face you'll have to look at when it's wrong. And write down your kill criteria before you build, because after you've built, you'll rationalize anything. None of this is as good as a great designer across the table or a 10x engineer ripping apart your PRD. It's the cheap substitute. But the cheap substitute beats nothing, and nothing is the default. ## **Balance is the job now** I don't know if "product manager" will survive as a title. Product management as a discipline will exist forever ([see PFTW #1](https://www.productftw.com/productftw-1-what-is-a-product-manager/)), and design and engineering aren’t going anywhere either. Someone still has to know the customer and the business, someone still has to make the thing usable, and someone still has to make it work. The only open question is how many bodies those disciplines live in. A tripod stands on its own. A pogo stick stays up only as long as the rider keeps their balance, and balance here means keeping all three disciplines honest when there's no peer left to do it for you. The one-person teams that thrive won't be the ones most skilled across the disciplines. They'll be the ones who know which of their legs is weakest and build the friction back in on purpose. Everyone else is about to ship slop faster than ever before. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### PRD AI Prompt - ProductFTW #88 URL: https://www.productftw.com/prd-ai-prompt/ Last updated: 2026-07-09T16:15:43.000Z You’re probably expecting this article to contain a prompt you can copy and paste into AI to generate a great Product Requirements Document. I understand why. Since publishing my PRD template, one of the questions I’ve been asked most often is whether I use AI to write PRDs and, if I do, whether I’m willing to share the prompt. The answer is yes, I use AI to draft nearly every PRD I write. It saves me a tremendous amount of time, helps organize complex ideas, and gets me to a strong first draft much faster than starting with a blank page. The answer to the second question is a little more complicated. I will share my prompt (it's down below), but I don’t think it will help you as much as you might expect. The quality of your PRD has less to do with the prompt than it does with the context you provide. A prompt tells AI how to organize information. It doesn’t give AI the product knowledge, customer insights, or business context needed to write a great PRD. This is also why I don’t believe AI replaces product management. If anything, it reinforces where product managers create the most value. Writing is the easy part of creating a PRD. The hard part is understanding the customer, identifying the right problem to solve, balancing competing priorities, aligning stakeholders, and making hundreds of small decisions throughout the discovery process. By the time a great PRD is written, most of the difficult work has already happened. If you’ve read [my previous article on why I think PRDs are still relevant](https://www.productftw.com/are-product-requirement-documents-still-relevant/), you’ll notice my [template](https://www.productftw.com/product-requirements-document-template/) focuses more on capturing context than documenting functionality. It starts with the problem statement, business context, user goals, and success metrics before it ever gets to requirements or user flows. I structured it that way because those sections capture the thinking behind the product, and that thinking is exactly what AI needs to produce a useful first draft. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. For example, imagine asking AI to write a PRD for recurring payments. Without any additional information, you’ll get a perfectly reasonable recurring payments feature. It will include common functionality, standard user stories, and requirements that make sense for almost any product, because AI fills in the gaps using patterns it has learned from thousands of similar examples. Most people recognize that’s not enough, so they take the opposite approach. They upload customer interviews, meeting notes, Slack conversations, Jira tickets, support requests, design files, technical documentation, and every other artifact they collected during discovery. The assumption is that more information will produce a better PRD. In my experience, it usually doesn’t. Discovery is messy, in part, because it is so human. The artifacts that come out of that process contain conflicting opinions, intentionally rejected ideas, open questions, outdated decisions, and stakeholder debates that were resolved weeks ago. A PRD isn’t a transcript of everything that happened during discovery. It’s a synthesis of the decisions that resulted from it. I’ve found that AI has no way of knowing which conversations mattered most or which decisions ultimately shaped the feature. It tries to synthesize everything I give it, even when some of that information shouldn’t influence the final PRD. I notice this most when I try to edit the PRD through a long conversation with AI. For example, I’ve had AI generate a draft that included support for scheduling recurring payments on different dates because the idea came up during discovery. We had already decided that functionality wasn’t part of the initial release, so I asked AI to remove it. Then I found another reference to it. Then another. Before I knew it, I’d spent the last fifteen minutes talking almost exclusively about why recurring payments on different dates weren’t supported. To me, I was making one relatively small correction. To AI, I’d spent the last fifteen minutes talking about a single feature. It started treating that decision as though it were one of the product's defining characteristics. Suddenly, the PRD had multiple callouts explaining why the feature wasn’t supported, references to it throughout the requirements, and additional notes clarifying the decision. At that point, I wasn’t writing the PRD anymore. I was managing AI. ![A meme showing a frustrated person yelling at their computer after spending over an hour arguing with an AI assistant. The screen displays a back-and-forth conversation with repeated corrections, while the caption reads, “POV: You’ve just spent an hour arguing with AI to accomplish a task that should only take 15 minutes.” Sticky notes, crumpled paper, and a digital clock showing “1:02 hours wasted” emphasize the humorous frustration.](https://www.productftw.com/content/images/2026/07/pov.jpg) Nobody talks about AI becoming your most high-maintenance coworker. I’ve found this happens more often than people realize. The longer the conversation goes, the more AI starts optimizing around the most recent discussion instead of maintaining a balanced understanding of the product. Eventually, you aren’t writing a PRD anymore. You’re trying to steer AI back toward the product you already understand. Trust me, this takes far longer than writing the PRD yourself. That’s why I don’t use AI to figure out what belongs in the PRD. By the end of discovery, I already know what the product is. I’ve been in customer interviews, stakeholder meetings, design reviews, and engineering discussions. I’ve already synthesized all of that information into a clear understanding of the problem we’re solving, the decisions we’ve made, and the tradeoffs we’ve accepted. Rather than dumping every artifact into AI or trying to teach it through an extended conversation, I give AI the product thinking I’ve already synthesized and ask it to challenge me. Instead of asking AI to write the PRD, I ask questions like: - What information is missing? - What assumptions am I making? - What edge cases haven’t I considered? - What questions would an engineer ask after reading this? - What questions would design ask? - What questions would QA ask? - What questions would compliance or support ask? - Is there anything here that feels ambiguous or contradictory? Here is a prompt I often use: > I want you to act as a skeptical cross-functional product team reviewing this feature before the PRD is written. Don’t make assumptions or invent requirements. Instead, identify gaps in my thinking. Tell me what information is missing, where my requirements are ambiguous, what edge cases I haven’t considered, what business rules need clarification, and what questions engineering, design, QA, compliance, legal, support, or operations are likely to ask before implementation. If something appears intentionally out of scope, ask me to confirm that assumption rather than expanding it. Your goal is to pressure-test my thinking, not to write the solution. Most of the time, I already know the answers because I was in the conversations. AI isn’t telling me something new. It’s reminding me of something I forgot to include. Occasionally, AI identifies a legitimate gap that I can’t answer. That’s valuable because it tells me there’s still product work to do before the PRD is ready. I can go back to a stakeholder, review the research, talk with engineering, or decide that the question is intentionally out of scope for this release. Either way, I’d rather make that decision before development starts than have the team debate it halfway through implementation. Once AI stops finding meaningful gaps, I know the product thinking is complete enough to document. That’s when I ask it to generate the PRD. At that point, AI isn’t inventing requirements or making product decisions. It’s organizing a product strategy that’s already been defined. Only after that process is complete do I ask AI to generate the PRD. ## The Prompt If you’re still looking for a PRD AI prompt, here’s a version of the one I use once I’ve synthesized the product thinking and pressure-tested it with AI. Notice that this comes after all of the work I’ve described above. The prompt isn’t doing the heavy lifting. It’s simply organizing information that’s already been validated. _This post is for subscribers only._ ### Real Life is Full of Edge Cases - ProductFTW #87 URL: https://www.productftw.com/real-life-is-full-of-edge-cases-productftw-87/ Last updated: 2026-07-02T17:54:09.000Z I’ve often been concerned about chasing edge cases. We’ve all worked with product managers or engineering leads who become obsessed with every unhappy path, leading to endless rework and delayed shipping. As the saying goes, “strategy is about what you say no to,” which is even more critical for product managers trying to define scope. I will admit to some fascination with edge cases. They are fun to think about. My personal blog was once called Cornercase for this very reason (you know, where two edges meet; it’s even rarer, like the Four Corners in the U.S.). ![Two-panel meme of a medieval knight. In the first panel, the knight confidently holds a sword labeled “My Perfectly Working Code.” In the second panel, an arrow labeled “Edge Case” pierces the knight’s helmet through the visor, implying that an unexpected scenario has broken otherwise functional code.](https://www.productftw.com/content/images/2026/06/edge-cases.jpeg) 99.9% success rate. Guess who was in the other 0.1%? While PMs are often cautioned not to chase edge cases, the reality is that life is full of them. In payments and fintech especially, edge cases are unavoidable because regulatory requirements mean you have to serve everyone, not just the average customer. For example, imagine you develop a mobile phone app. You have a bug that causes the app to crash on launch in iOS 18.4, but not in any other version. As of today, only 0.31% of all U.S. iPhones run this version ([StatCounter](https://gs.statcounter.com/ios-version-market-share/mobile/united-states-of-america/?ref=productftw.com)). Should you fix it? Maybe not. If it’s a game or social app, you might decide that supporting a tiny percentage of users isn’t worth delaying the release. Given the rapid pace of iOS upgrades, that version will eventually disappear. Now imagine you’re building a fintech app and iOS 18.4 is the only version supported by a visually impaired customer who relies on accessibility features that changed in later releases. Or imagine it’s the only device they own. Suddenly, that 0.31% isn’t just a statistic. It’s a customer who may no longer be able to access their money. Banks and regulators tend to care a lot more about those situations than game developers do. Edge cases exist everywhere, from the technology you support to the data you collect. One of my favorite examples in fintech is addresses. They seem simple enough: 1. Everyone has one 2. You can look them up at the USPS or a mapping tool 3. Regulators require you to have a real physical address, not a PO Box Except: 1. Some people have weird addresses, like folks in [Carmel-by-the-Sea](https://www.cbc.ca/radio/asithappens/carmel-no-addresses-1.7091347?ref=productftw.com) (ok, they are getting addresses) 2. Some people in rural areas have rural route numbers 3. Minnesota has a law allowing people to use a PO Box as their official address in its anti-stalking statutes 4. Some people can’t accept physical mail to their home address (condos, rural areas) These situations seem rare, but within your first few thousand customers you’ll almost certainly encounter them. With limited data, it’s difficult to know which ones are worth investing in upfront and which ones can wait. The same pattern appears throughout fintech. Once you start looking, almost every piece of customer information has its own collection of edge cases. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. **Identity** - Someone legally has only one name. - A customer’s name is longer than your database allows. - They recently changed their name, but not every system has been updated. - Their legal name contains accented or non-Latin characters. **Phone Numbers** - The customer doesn’t have a mobile phone. - They recently changed numbers. - Multiple family members share the same phone number. - They can’t receive one-time passcodes. **Email** - The customer no longer has access to the email address they registered with. - Verification emails end up in spam. - Your validation rejects a perfectly legitimate email address. **Dates** - Leap-day birthdays. - A customer turns 18 today for KYC purposes. - Time zones affect payment cutoffs. - Daylight Saving Time changes when scheduled payments execute. **Cards & Payments** - Gas station authorization holds. - Hotel and rental car incidental holds. - Restaurants adjusting transactions after tips. - Partial reversals and duplicate authorizations. - Merchants taking days to reverse an authorization. None of these situations is common on its own. Collectively, they are inevitable. If you build products for enough customers, especially in a regulated industry, you’ll eventually encounter all of them. Some of the most interesting edge cases aren’t even software problems. They’re ecosystem problems. Take gas stations. When you pay at the pump, the merchant estimates your purchase amount and places an authorization hold before you begin fueling. Some issuers add their own padding on top of that. The result can create several frustrating experiences: - The hold is too small, so you can’t fill your tank. - The hold is too large, so you don’t have enough available funds for other purchases. - The authorization takes days to clear, leaving your money unavailable long after you’ve finished pumping gas. This is why so many debit cards recommend paying inside. The cashier enters a fixed purchase amount, avoiding the uncertainty of a variable authorization hold. It’s a problem I’ve been thinking about for nearly twenty years. Gas prices have changed dramatically over that time, but the underlying customer experience hasn’t improved much. ## How to Handle Required Edge Cases Not every edge case deserves engineering effort. Part of being a product manager is deciding which problems are worth solving and which ones aren’t. Legal and regulatory requirements are different. They are still edge cases, but they aren’t optional. You have to support them, and you have to do so efficiently. One approach is to build software that handles every scenario automatically. Another is to provide operations or customer support teams with administrative tools that enable them to resolve uncommon situations manually. While this introduces some operational overhead, it often allows you to ship sooner without compromising compliance or customer outcomes. The goal isn’t to eliminate every edge case before launch. It’s to understand which ones are simply rare, and which ones are guaranteed to happen eventually. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Product Requirements Document (PRD) Template - ProductFTW #86 URL: https://www.productftw.com/product-requirements-document-template/ Last updated: 2026-06-25T16:15:38.000Z Last week, I wrote about why I think [Product Requirement Documents are still relevant](https://www.productftw.com/are-product-requirement-documents-still-relevant/). My stance is that I no longer really think of PRDs as documentation; instead, I think about them as a way to preserve context. After publishing that article, several people asked what my PRDs actually look like. The truth is that there is nothing particularly revolutionary about the template itself. If you search online, you will find hundreds of PRD templates that look similar. It doesn’t matter what the sections are or exactly how its formatted. What matters is how the document gets used. Over the years, I have found that the most effective PRDs are collaborative documents. Product starts the conversation, but Product should not be the only team contributing to it. This is the [PRD template](https://www.productftw.com/templates-product-requirements-document/) I use most often. ![A MacBook displaying the ProductFTW PRD Template, showing section headings including Overview, Problem Statement, Why This Matters, Background, and User Goals.](https://www.productftw.com/content/images/2026/06/prd-template.png) ## **Start With the Problem** The first thing I will write is the overview. My goals are to clearly define the problem we are solving, why it matters, and any important context the team needs to understand before they start proposing solutions. For example, if I were building a repayment experience for a credit card product, I might write: > Today, cardholders have limited visibility into their repayment options and upcoming obligations. Users frequently contact support with repayment-related questions, miss payment deadlines, or struggle to understand their current account standing. > > This initiative aims to improve the repayment experience by helping users better understand their obligations, successfully complete payments, and avoid preventable delinquency events. That statement sounds simple, but it immediately gives the team a shared understanding of the goal. The focus is on the problem while avoiding implementation details such as buttons, APIs, or database tables. ## **Write User Goals Before Requirements** One mistake I see product managers make is jumping directly into requirements. Before I start writing requirements, I want to understand what the user is actually trying to accomplish. For the repayment example, some user goals might be: - I need to understand how much I currently owe. - I need to understand when my next payment is due. - I need confidence that my payment obligations will be met on time. - I need to avoid unnecessary fees and penalties. - I need visibility into my account standing and repayment status. - I need to quickly resolve repayment issues when they occur. - I need confidence that my payment was successfully processed. - I need to understand what actions I can take if I am unable to make a payment. One thing I try to avoid is writing features as user goals. “Users need scheduled payments” is not a goal. “Users need confidence that their payments will be made on time” is a goal. Scheduled payments may be one way to solve that problem, but they should not be assumed before the team has had a chance to explore solutions. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **Define Success Before You Define Solutions** Once I understand the user goals, I define how we will know whether we successfully solved them. For the repayment example, I might identify success metrics such as: - Reduction in late or missed payments - Reduction in delinquent accounts - Reduction in repayment-related support contacts - Increase in successful repayment completion rates - Increase in on-time payment rates - Increase in users successfully managing repayments without assistance I try to keep this section simple as another effort to help prevent jumping directly into solutions. The goal is to create agreement around how we will determine whether the initiative was successful. If this section starts to feel like you are trying to build out a full reporting dashboard, you’ve missed the mark. If the user goal is confidence that payments will be made on time, and the success metric is reducing missed payments, there are many possible ways to solve that problem. Scheduled payments might be one solution, but they should not be assumed before the team has had a chance to explore options. Once I understand the problem, the user goals, and how we will measure success, then I start thinking about the work itself. ## **Use Epics to Organize Complexity** This is where epics come in. For the repayment example, I might identify epics such as: - Payment Experience - Scheduled Payments - Payment History - External Account Linking - Delinquency Management - Customer Communications At this stage, I am still not worried about implementation details. I am simply organizing the problem into manageable pieces. ## **Key Requirements Come Next** Only after I understand the major areas of work do I start writing key requirements that focus on what must be true for the experience to succeed. These are not my user stories, at least not yet. Examples might include: - Implement a Payments screen with navigation and sections for single payments and payment methods. - Allow users to enter or select predefined payment amounts (Minimum, Statement, Current) and choose a payment date. - Only one scheduled payment is allowed at a time; additional attempts show an inline error. - … and more I try to focus on business rules and outcomes rather than implementation details. (Are you noticing a theme?) ## **Map the User Flows** The last section I fully own as a product manager is user flows. The purpose of this section is to document how users navigate the experience and identify key decision points. For example: 1. User selects Pay. 2. User enters payment amount or selects payment type. 3. User selects payment date. 4. User confirms submission 5. Payment is scheduled. 6. Confirmation email is sent. This gives Design and Engineering a clear understanding of what the experience should accomplish before they begin designing or building it. ## **The Document Becomes Collaborative** This is where my process differs from many templates. Once I have completed the overview, user goals, epics, key requirements, and user flows, I schedule time with my design lead and technical lead. We walk through the initiative together. At that point, Design becomes responsible for Design Requirements, and Engineering becomes responsible for technical and Security Requirements. Rather than Product trying to write everything, the experts contribute their own requirements to the same document. The result is a PRD that reflects how the entire team thinks about the problem rather than just how Product thinks about it. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **Future Considerations, Dependencies, and FAQs** The remaining sections help preserve context as the project evolves. - Future Considerations capture ideas that are important but out of scope. - Assumptions and Dependencies capture external systems, vendors, approvals, and other risks. - The FAQ section becomes a running record of important questions and decisions. Over time, these sections often become some of the most valuable parts of the document because they explain why decisions were made. ## **Check Out the Template** The [PRD template](https://www.productftw.com/p/7d04fb70-fe73-4cc4-b4cc-7a5542071742/) itself is simple. The value does not come from having the perfect structure. The value comes from creating a shared understanding of the problem before the team starts building. If you have been looking for a lightweight PRD template that works well for startups and growing product teams, feel free to [steal this one](https://www.productftw.com/p/7d04fb70-fe73-4cc4-b4cc-7a5542071742/) and adapt it to your own process. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Are Product Requirement Documents Still Relevant - ProductFTW #85 URL: https://www.productftw.com/are-product-requirement-documents-still-relevant/ Last updated: 2026-06-18T16:15:34.000Z Two years ago, Zach wrote [*Mastering the Art of Requirements: PRDs that Actually Work*](https://www.productftw.com/mastering-the-art-of-requirements-prds-that-actually-work/) and made a strong case for why Product Requirement Documents still matter. His argument was that a PRD should not be viewed as a static document that gets written once and forgotten. Instead, it should serve as a living source of truth that helps teams stay aligned as a product evolves. At the time, the conversation was largely centered around whether PRDs were too heavy for startups. Most early-stage teams are moving quickly, resources are limited, and nobody wants to spend weeks writing documentation that nobody reads. I think that was a fair concern then, and honestly, it is still a fair concern now. What has changed is the environment we are building in. If you spend any time on LinkedIn or product blogs, you’d probably think PRDs are on their way out. Product briefs are popular, AI can generate requirements in seconds, and everyone seems to be looking for a faster way to communicate. When AI first started showing up in product workflows, I assumed we would need less documentation. If a model could summarize meetings, generate requirements, write tickets, and even create prototypes, then surely the need for a detailed PRD would start to disappear. What I’ve found is the exact opposite. ## **All Product Documents Are Trying to Accomplish the Same Thing** One thing I have noticed over the years is that product managers spend a surprising amount of time debating formats. Should you write a PRD? Should you write a product brief? Should everything live in Linear? Should requirements be written as user stories? Should you just record a Loom video and call it a day? Most of these approaches are trying to accomplish the same thing. They are helping a team understand what is being built, why it matters, who it is for, and what success looks like. I've seen teams ship great products from a one-page brief, and I've seen teams struggle with a twenty-page PRD. I've also seen the opposite happen. The difference is usually not the document itself. The difference is whether the team actually understands the problem they are trying to solve. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **Why I Keep Coming Back to PRDs** I have experimented with many approaches over the years, and I always find myself coming back to some version of a PRD. The reason is pretty simple. I think best when I write. Every time I try to skip that step, I end up writing the same information somewhere else because I need a place to organize my thoughts. Writing forces me to identify gaps in my assumptions, clarify what is actually important, and think through the problem before I start asking other people to spend time on it. Once the document exists, it becomes something I can use with engineering, design, executives, and stakeholders. I can walk through it in a meeting. I can turn it into a presentation. I can reference it weeks later when someone asks why a decision was made. People process information differently. Some people prefer reading. Some prefer diagrams, and others need to talk through an idea before it clicks. The PRD gives me a starting point that supports all those communication styles. ## **An Example** One reason I still believe in documenting requirements is that product problems are almost always more complicated than they appear at first glance. Let’s say we want to build a repayment experience for a credit card product. On paper, that sounds pretty straightforward. We want users to be able to repay their balance conveniently and accurately while maintaining compliance requirements. In reality, there are months of work hiding behind that one sentence. Users need to make payments, schedule future payments, connect bank accounts, understand their account standing, and know what happens when something goes wrong. Customer support needs visibility into repayment activity. Compliance needs disclosures and regulatory safeguards. Engineering needs integrations with external systems and a plan for handling edge cases. What started as a simple repayment feature has now become a large cross-functional initiative. Without a shared understanding of the problem, product, design, engineering, compliance, and customer support can easily end up solving different versions of the same challenge. Everyone is working hard, but they are not necessarily working toward the same outcome. Documenting the problem early gives the team a chance to align on what matters before they start debating solutions. ## **AI Changed the Value of Requirements** The part I did not anticipate two years ago is how AI would change the value of requirements. Historically, requirements existed primarily to help humans understand what to build. Today, requirements are increasingly consumed by both humans and machines. What I’ve found is that AI has not reduced the need for documentation. It has dramatically increased the amount of information generated about a project. We now have AI-generated meeting summaries, AI-generated tickets, AI-generated user stories, AI-generated test plans, AI-generated wireframes, and AI-generated prototypes. All of those things can be useful, but they also create a new challenge. Every time information gets transformed, there is an opportunity for context to disappear. ![Hand-drawn comic illustrating the “product game of telephone.” A product manager starts with the goal “Help users avoid late fees with a repayment experience.” As the idea passes through an AI summary, ticket, user story, planning meeting, and release notes, the original intent becomes increasingly diluted. A sticky note labeled “Source of Truth” sits at the center, connecting each stage and emphasizing the importance of preserving context. The comic humorously shows how requirements can drift as information is summarized and transformed across teams and tools.](https://www.productftw.com/content/images/2026/06/productftw-85.jpg) Some context may have shifted during transmission. A meeting becomes a summary. A summary becomes a ticket. A ticket becomes a feature. A feature becomes release notes. The further you get from the original source, the easier it becomes to lose the details that actually mattered. What I’ve realized over the last year is that I no longer really think of PRDs as documentation. I think about them as a way to preserve context. When multiple people and multiple AI systems are generating outputs for the same initiative, having a single place to define the problem, goals, requirements, assumptions, and constraints becomes incredibly valuable. It allows everyone to continuously refer to the original intent rather than relying on increasingly summarized versions of the work. In many ways, a good PRD has become one of the most valuable prompts a product manager can create. The quality of AI outputs is directly tied to the quality of the information that goes in. A well-written requirements document can generate tickets, identify gaps in logic, create prototypes, and help build portions of a product. ## **What Changed** Looking back, I think Zach’s core point was right. The value of a PRD was never the document itself. The value was creating a shared understanding of the problem so that everyone could move in the same direction. Two years later, I still believe that is true. What changed is that we now live in a world where information is constantly being generated, summarized, transformed, and repackaged by both humans and AI. What used to be a useful artifact has become an important anchor for preserving context. Call it a PRD, a product brief, a strategy document, or something else entirely. What matters is that your team has a place where the original intent of the work can live. That is what good requirements have always been about, and I suspect that will still be true two years from now. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### The Product Management Career Path - ProductFTW #84 URL: https://www.productftw.com/the-product-management-career-path/ Last updated: 2026-06-11T16:15:52.000Z One of the things I love about product management is that there is no single path into the profession. Unlike careers where there is a clear degree, certification, or entry-level role that everyone follows, most product managers arrive here from somewhere else. Even though many companies now have Associate Product Manager programs, product management is not really an entry-level career. Most people spend a few years building expertise in another area before making the transition. Some come from engineering, others come from design, and many come from operations, analytics, customer support, project management, or marketing. The common thread is that they develop a deep understanding of a problem and eventually become interested in solving it. What many successful product managers share is strong product taste. I talked about product taste in [*Why Card Products Can’t Ship Like AI Products - ProductFTW #80*](https://www.productftw.com/productftw-80-why-card-products-cant-ship-like-ai-products/), but in short, it’s the ability to recognize a great user experience. It is knowing what feels intuitive, what feels frustrating, and what would make a product more useful for the people who rely on it. Most product managers develop that sense by spending a lot of time living with the problem themselves. We often call it "eating your own dog food" because you become both the user and the person identifying opportunities for improvement. That was exactly how I found my way into product. My first role at CreditCards.com was called Product Information Management, but in reality, it was mostly data entry using a collection of legacy tools. My job was to take feedback from credit card issuers and update information across our affiliate websites to make sure everything was accurate. The more time I spent using those systems, the more opportunities for improvement I noticed. I was training other employees, documenting processes, and working through the same workflows every day, which gave me a front-row seat to all of the friction in the product. Eventually, I started giving feedback directly to engineers because I could clearly see how the tools should work and where they were creating unnecessary effort. At the time, I did not even know product management was a career. I simply knew that I was more interested in fixing problems than working around them. Having worked with many product managers now, I’ve learned that’s how many get their start. They become the person who understands a problem deeply enough to see a better way forward and can communicate that vision clearly enough for others to build it. Regardless of where a product manager starts, career progression usually follows a similar path. What changes over time is the scope of the problems or products you manage and how much of the strategy you own. ![nfographic showing the product management career path from Associate PM to Product Manager to Senior PM, then splitting into Management and Individual Contributor tracks. The chart highlights increasing scope and influence from features to company-wide impact.](https://www.productftw.com/content/images/2026/06/ProductFTW--84-5.png) Product management has two endgames: build teams or become the person everyone calls when things get weird. [Product Management Career Path - ProductFTW #84Download and share the Product Management Career Path with coworkers and friends.Product Management Career Path - ProductFTW #84.pdf757 KBdownload-circle](https://www.productftw.com/content/files/2026/06/Product-Management-Career-Path---ProductFTW--84-1.pdf "Download") ## Associate Product Manager The first step into product is usually some variation of Associate Product Manager, Junior Product Manager, or Product Manager I. At this stage, you are typically responsible for a small piece of a larger product or a relatively low-risk initiative. The goal is not to set company strategy or redefine the business. The goal is to learn how product development works while proving that you can consistently deliver results. One of my first projects was helping replatform a small affiliate website. It was not a major business priority, and very few people outside the team paid attention to it, which made it the perfect environment to learn. I was given a few engineers and asked to figure out how we could modernize the site while ensuring it remained easy to maintain going forward. That project eventually led to bigger opportunities because product careers tend to compound. Once people trust you to solve one problem, they start giving you larger and more important ones to solve. The experience can look very different depending on the company. In a large organization, you are likely working closely with a senior product manager who reviews your decisions and helps you avoid mistakes. In a startup, you are often expected to learn much faster because there are fewer layers of support. ## Product Manager Once you demonstrate that you can consistently execute, your scope begins to expand. Instead of owning a small feature or project, you begin owning products, larger business objectives, and more meaningful metrics. At this stage, someone else is still generally setting the broader strategy, but you are responsible for figuring out how to execute against it successfully. For me, that transition happened when I took ownership of [CardMatch](https://www.creditcards.com/cardmatch/?ref=productftw.com), which is a product designed to match consumers with credit cards that fit their needs. The visibility and business impact were significantly larger than anything I had worked on previously, and success was measured by outcomes rather than simply whether a project launched on time. This is where many product managers spend the majority of their careers. They become experts in prioritization, stakeholder management, customer discovery, roadmap execution, and driving measurable results. ## Senior Product Manager The transition from Product Manager to Senior Product Manager is usually when strategy starts to become a larger part of the job. You are no longer focused exclusively on delivering features. You are thinking about why those features matter, how they connect to the company's broader goals, and whether there are better opportunities to pursue. After CreditCards.com was acquired by Red Ventures, there was a major push toward personalization across multiple websites. My work expanded beyond individual products and into initiatives that affected an entire portfolio of products. That shift from managing a single product to influencing multiple products is often what separates a Senior Product Manager from a Product Manager. At this level, you spend more time defining the roadmap than simply executing it. You begin to influence strategic decisions, evaluate trade-offs, and help leadership understand where the business should invest its resources. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## The Fork in the Road After reaching the Senior Product Manager level, most product managers eventually choose between two different paths. The first path is management, where your primary responsibility becomes developing people and building teams. The second path is the individual contributor track, where your primary responsibility becomes solving increasingly complex product problems. Neither path is better than the other. They simply require different strengths and interests. In larger organizations, the split is usually very intentional. The management path leads through Director, Vice President, and eventually Chief Product Officer. The individual contributor path often progresses through Principal Product Manager and, in some organizations, Distinguished Product Manager. These roles often carry influence and compensation comparable to leadership positions, but they focus on solving the company's hardest product challenges rather than managing people. Larger organizations also tend to create additional levels within both tracks. The management ladder does not simply move from Director to Vice President. Many companies include Group, Senior Director, Vice President, Senior Vice President, Executive Vice President, and other levels before reaching the executive suite. The same pattern exists on the individual contributor side, where organizations may have multiple Lead, Principal, or Distinguished levels. The exact titles vary significantly from company to company, which is why I think it is more useful to think about product careers in terms of scope and influence rather than titles. As your career progresses, your responsibility expands from a feature to a product to multiple products and eventually to entire business lines, regardless of which path you choose. ## The Management Track The management track usually begins with the Director of Product. These roles spend less time directly managing products and more time managing product managers. Their responsibility shifts toward coaching, hiring, resource allocation, performance management, and ensuring that teams are focused on the right priorities. As you continue progressing through Senior Director and Vice President roles, the focus becomes increasingly strategic. You spend more time working with executive leadership, managing budgets, evaluating investments, and ensuring that product efforts align with broader business objectives. When I became a Director, I was responsible for managing four product managers. When I eventually moved into a Vice President role, I was managing directors who were managing their own teams. The work became much less about individual products and much more about building an organization capable of consistently delivering great products. ## The Individual Contributor Track The individual contributor path is often less understood because many startups do not have a formal IC ladder. In organizations that do so, the path typically progresses from Senior Product Manager to Lead Product Manager, and then to roles such as Principal Product Manager and Distinguished Product Manager. What makes the individual contributor path unique is that your influence continues to grow without adding direct reports. In many cases, senior ICs are coordinating more teams and stakeholders than their management counterparts because they are responsible for solving the company's most important cross-functional problems. A Lead Product Manager might lead a strategic initiative that requires alignment across half a dozen teams. A Principal Product Manager might help define strategy for an entire business unit while serving as a trusted advisor to executives and product leaders. Distinguished Product Managers are often brought in to address the company's most difficult challenges because they have built a reputation for consistently finding the right solutions and helping organizations navigate complex decisions. While managers create leverage through people, individual contributors create leverage through expertise, influence, and execution. Their role is often highly consultative, and their ability to align teams that do not report to them is what makes them effective. ## The Real Career Path The interesting thing about product management is that the titles matter far less than most people think. Throughout your career, you identify problems, understand customers, work with teams to build solutions, and measure their impact. It is a lot of rinse-and-repeat, but the scope of your purview changes the higher you move up the ladder. If you are looking to get into product management but don’t know where to start, you are probably closer than you think. Focus on the issues in your current role, [interview your coworkers](https://www.productftw.com/templates-how-to-conduct-user-interviews/), and determine the best solution. If this comes easily to you and you are passionate about solving problems, it is time to start climbing the PM career ladder. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### The Card PM's Day: What You Actually Do - ProductFTW #83 URL: https://www.productftw.com/the-card-pms-day-what-you-actually-do/ Last updated: 2026-06-04T19:27:35.000Z **TL;DR** - A card PM's day is dominated by *partner engagement:* bank sponsor, processor, networks, fraud, and compliance. - The real job is owning tradeoffs nobody else will: friction vs. fraud, speed vs. compliance, rewards generosity vs. unit economics. - Most of your roadmap is non-negotiable work imposed from outside (network mandates, regulatory changes, partner audits) - The PMs who thrive treat constraints as core to the product, not as obstacles. - If you're trying to break in, learn the money flow first. The features make sense only once you understand how the program makes (and loses) money. A good joke in product management is that the job description means something different to everyone. Someone who works on a continuous-development web product has a very different role from someone who makes packaged (installed) software, like core apps on a desktop. Similarly, the tasks and responsibilities of a fintech card product manager differ significantly from those of a traditional software PM. Often, the role takes on a greater business or general management function. After building card and payment products at Green Dot, Wallaby, Bankrate, Apto, and Vertical Finance, here’s my take. ## Wake Up to New Constraints and Requirements A software PM usually opens the day inside their own loop: standup, designs, and the backlog. A card PM opens the day inside *other companies'* loops. Before I look at my own roadmap, I'm usually dealing with: - An email from the **bank sponsor** asking for a change to a disclosure, a marketing review, or evidence for an upcoming audit. - A **processor** ticket: the settlement file looked off, or a new feature needs a config change on their side that's gated behind their release cycle, not mine. - A **network** bulletin (e.g., Visa, Mastercard) announcing a mandate with a compliance deadline I didn't choose and can't negotiate. - A reconciliation exception: the **bank sponsor** report, **processor** settlement file, and **network** data don’t agree, and someone needs to figure out where the discrepancy originated before it becomes a customer or finance problem. None of that was on my roadmap. All of it is now my problem. The first skill of a card PM is triaging externally-imposed work against the things you actually wanted to build, because the external work has hard deadlines and real penalties, and the internal work doesn't. ![A product manager with dark-rimmed glasses working at a desk in a sunny Los Angeles office. A yellow stuffed dog with pointy ears sits beside a laptop, while palm trees and mountains are visible through the window.](https://www.productftw.com/content/images/2026/06/card-pm-day.jpg) The stuffed dog is optimistic. He still thinks we’re getting to the roadmap this afternoon. ## Even when all trade-offs feel bad, you still have to make them! Here's the part that surprises people: the most important things I decide in a week aren't features. There are tradeoffs that sit between teams, where each team optimizes for its own metric, and someone has to own the whole. - **Friction vs. fraud.** The risk team wants more verification steps; growth wants fewer. Every step you add kills some legitimate signups and stops some fraud. That curve is a product decision, and the PM owns where you sit on it. (This is why [authentication in fintech](https://www.productftw.com/productftw-66-authentication-in-fintech/) is a product problem, not an engineering checkbox.) - **Speed vs. compliance.** Engineering can ship the feature in a sprint. Legal needs three weeks and a change to the disclosure. The PM decides what "done" means and sequences the work so the launch is real, not a demo that can't go live. (See [Managing the Legal Files](https://www.productftw.com/productftw-41-managing-the-legal-files/).) - **Generosity vs. unit economics.** Richer rewards drive signups and destroy margins. When rewards post, how repayment works, which payment options you surface: these *feel* like settings and are actually the economics of the program. (More in [Why Rewards Timing Matters](https://www.productftw.com/productftw-71-why-rewards-timing-matters/) and [Credit Card Repayment Timing Is a Product Decision](https://www.productftw.com/productftw-68-credit-card-repayment-timing-is-a-product-decision/).) A generalist PM can have a great career without ever touching a P&L. A card PM who can't read the program economics is just taking dictation from the finance team. ## Getting to the core product work The middle of the day looks more familiar: working with design and engineering on the things you *do* control. It’s not photo sharing, as I like to say (sorry, photo-sharing PMs). A bug in Instagram is an annoyance. A bug in a card product can double-charge someone, decline a legitimate purchase at the worst moment, or expose data that triggers a regulatory filing. That's why card products [can't ship like software products](https://www.productftw.com/productftw-80-why-card-products-cant-ship-like-ai-products/): the operational discipline–testing, staged rollout, reconciliation, and rollback plans are heavier because the consequences are irreversible. Today, systems are far more resilient, but I can recall outages that left cardholders at the lower end of the spectrum unable to pay for food or gas. That is not OK. You simply cannot lose people’s money! When something does go wrong, the [support experience becomes the product](https://www.productftw.com/productftw-44-why-great-support-creates-loyal-users/). A card PM spends real time on the unhappy path (disputes, declines, locked accounts) because that's where trust is won or lost. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## So, why do you like fintech? Good question. When I left Green Dot in 2009, I took a detour from fintech to work at [yellowpages.com](http://yellowpages.com/?ref=productftw.com). I thought it would be so great to ship code all the time, work on the web, and avoid banks. First lesson: if you want to avoid compliance issues, a company owned by AT&T isn’t a good call. Second lesson: you can’t ignore your passions! I enjoyed my time at AT&T and learned a lot there. However, the challenge of building reliable, secure, and life-critical fintech products holds an enduring allure for me. The higher stakes and the bigger challenges are motivating. I still build some apps on the side for fun, but I bring my desire for precision and accuracy over from fintech, rather than taking a break from it. Fintech is more serious than many apps, but it is not as serious as medical research or the software that powers rockets. I don’t think fintech is directly life-or-death, but it is very serious. I enjoy the higher standard and working with my partners across the fintech stack (even if I sometimes wish banks would respond to compliance requests more quickly!). ## Lessons for getting into fintech The most common mistake I see from PMs trying to move into fintech is leading with feature ideas. The fintech interviewer doesn't care about your feature instincts yet; they want to know if you understand the *money flow*. Where does revenue come from (interchange, interest, fees)? Who are the partners, and what does each one control? What can the PM actually decide versus what's imposed by the network or the regulator? Learn that first, and the features make sense. Skip it, and you'll design beautiful flows that legal kills in week one. The fastest way to learn the business your product lives inside is to read the card industry from the inside, which is exactly what our sister publication, [CardsFTW](https://www.cardsftw.com/?ref=productftw.com), exists to teach. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### User Interview Template - ProductFTW #82 URL: https://www.productftw.com/user-interview-template-productftw-82/ Last updated: 2026-05-21T19:10:02.000Z ![Image of a macbook laptop with the How to Conduce User Interviews guide page open.](https://www.productftw.com/content/images/2026/05/how-to-conduct-user-interviews-1.png) [View Guide](https://www.productftw.com/templates-how-to-conduct-user-interviews/) Last week, Jessica wrote about one of the [biggest mistakes teams make during user interviews](https://www.productftw.com/the-biggest-mistake-you-can-make-during-user-interviews/): treating them as validation exercises rather than discovery conversations. We don’t want to just pitch problems. The follow-up questions are obvious: - “What questions should I actually ask?” - “How should I structure interviews?” - “What does a good discovery conversation look like?” Good questions, let’s dig in with this quick user interview template and guide that product teams can use to run better discovery conversations and uncover real customer pain before building features. ## **What’s Inside** The guide includes: - a simple interview structure - workflow questions - pain point questions - workaround questions - impact questions - examples of what NOT to ask - common interview mistakes The framework is designed to help teams better understand: - how users actually work - where workflows break down - what frustrations repeat consistently - what problems are painful enough to solve ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **One of the Most Useful Interview Shifts** Most weak interviews focus on hypothetical behavior. Strong interviews focus on real past behavior. Instead of asking: > “Would you use this?” Ask: > “Walk me through the last time you had to do this.” That one change alone tends to produce dramatically better discovery conversations. ## **Read the Full Guide** If you’re doing: - product discovery - customer research - roadmap planning - UX research - early-stage product validation This guide should help you run more useful user interviews and uncover more actionable insights. Read the full User Interview Template + Guide here: [View Guide](https://www.productftw.com/templates-how-to-conduct-user-interviews/) ## **More ProductFTW Resources** - [**Product Brief Template**](https://www.productftw.com/templates-product-brief/) - [**API Evaluation Checklist**](https://www.productftw.com/templates-api-evaluation-checklist/) - [**Fintech Breakage Checklist**](https://www.productftw.com/templates-fintech-breakage-checklist/) # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### The Biggest Mistake You Can Make During User Interviews - ProductFTW #81 URL: https://www.productftw.com/the-biggest-mistake-you-can-make-during-user-interviews/ Last updated: 2026-05-22T02:26:17.000Z ## TL;DR - The biggest mistake in user interviews is walking in with a conclusion and treating the conversation as validation instead of discovery. - "Would you use this feature?" is the wrong question because users are bad at predicting their own future behavior and tend to say yes to sound polite or aspirational. - The worst outcome of a bad interview isn't learning nothing, it's learning the wrong thing and feeling confident about it ![Anime-style illustration of an overly enthusiastic person shoving a tablet at a visibly uncomfortable user during an interview, with an unopened notebook of user research questions sitting between them.](https://www.productftw.com/content/images/2026/05/user-interview.png) She did not, in fact, want this feature. A couple of weeks ago, in [*You Don't Have a Roadmap Problem. You Have a Problem-Definition Problem*](https://www.productftw.com/productftw-77-you-dont-have-a-roadmap-problem-you-have-a-problem-definition-problem/)I talked about how it's not uncommon for a company or founder to know what they want to build and who might pay for it, but they can't tell you what problem the feature actually solves for the user. So how do you figure out the problem? Our generic advice is usually "go talk to users." User interviews are part art and part science. After observing and coaching on conducting the best interviews, I’ve noticed a common pattern that leads to the worst outcomes for companies and users. ## The Pattern The goal of the interview is to come out the other side with a clearer picture of where the real friction is in your user's life. Sometimes that confirms the problem you suspected, and other times it surfaces a problem you didn't know existed. Sometimes it tells you the problem you were going to solve isn't actually that painful, and you just saved yourself six months of building the wrong thing. The biggest mistake I see is that the person or team running user interviews isn’t actually conducting the interviews to learn about their users. Instead, they’ve already decided what they want to build, and they are just looking for validation, so the questions they ask are the ones you'd expect from someone looking for a yes: - "We're thinking about building a feature that does X. Would you use it?" - "If we added the ability to do Y, would that be valuable to you?" Some users say yes, and that gets logged as validation. Other users say no, and that gets explained away as if they didn’t get it, they’re not the target customer after all, or they’re an edge case. Maybe all of those are true, but it doesn’t matter because the team walked into the conversation with a conclusion and walked out with the same conclusion. There’s no new insight or real learning, just a paper trail of “we talked to users.” ## Why This Doesn't Work When you go into an interview looking for confirmation, no answer can actually change your mind. You've already decided what counts as signal and what counts as noise before the conversation starts. Even when teams are genuinely open to learning, these types of interviews don’t yield many useful insights because users are bad at predicting their own future behavior. Ask someone whether they'd use a hypothetical feature, and they'll almost always say yes, especially if you sound excited about it. This can be for a number of reasons, including that they're being polite, they're pattern-matching to what you seem to want to hear, or they're aspirationally imagining a version of themselves who might use the feature being built, even if that doesn’t match their actual behavior. None of that translates into adoption when a feature ships. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## What To Ask Instead The interviews that surface real insight focus on how someone actually does their job (or whatever activity your product helps them with), what frustrates them, where they lose time, and what workarounds they have invented to deal with the gaps. Some questions that get there: - "Walk me through the last time you had to do X. What did you actually do, step by step?" - "What's the most frustrating part of your week?" - "Where do you feel like you're wasting time?" - "What have you tried to fix this? What worked? What didn't?" - "If this problem went away tomorrow, what would change for you?" Notice what's missing? None of these mention your product, your roadmap, or any feature you are considering. They are entirely about the user's reality. You are not selling, you are not validating, you are just listening for pain points. ## When Feature Questions Are Okay Feature questions belong in the conversation only after you've defined the problem and have a specific solution to test, and the framing should be something more like "how would this fit into your workflow" not "would you use it." The reason the framing matters is that you've now anchored the conversation in their problem instead of your idea. They can give you a useful answer instead of a polite one because they actually have the context. Better still, hand them a prototype and watch them try to use it. Observing behavior beats stated preference every time. ## What You're Actually After The biggest mistake isn't running bad interviews; it's walking into them with a conclusion already in mind. The worst outcome isn’t that you learn nothing, it’s that you learn the wrong thing and feel good about it. Better questions help, but the real fix is changing what you're trying to get out of the interview in the first place. You’re not there to test an idea. You're there to understand your users' problems. Listen for what frustrates them, not for openings to mention your feature. Try to better understand where their problems are being underserved. You'll know it worked when you walk out with a problem you weren't expecting, or with the same problem described more sharply than you described before the interview. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Why Card Products Can’t Ship Like AI Products - ProductFTW #80 URL: https://www.productftw.com/productftw-80-why-card-products-cant-ship-like-ai-products/ Last updated: 2026-06-04T19:27:32.000Z 🙏 ProductFTW is made possible in part by our paid subscribers. If you’re one of them, thank you. If you’re not, please consider supporting ProductFTW (who knows, maybe you can expense it!) My friend sent me a link to Lenny Rachitsky's [podcast with Cat Wu,](https://youtu.be/PplmzlgE0kg?si=FX3%5F1ocy7lq%5FLEha&ref=productftw.com) who leads product for Claude Code, and the conversation stuck with me for two reasons. First, I kept thinking about whether the way AI teams ship products translates to card products. Second, I kept coming back to this idea of “product taste” and why it is so hard to define. A quick summary of the conversation: Anthropic has reduced its shipping cadence from months to weeks to days, and that is redefining what they look for in PMs. They want people who can see problems early, move quickly, and build even when the product is not fully there yet. The emphasis is less on perfect execution and more on judgment. Can you pick the right problems, iterate fast, and know what matters as the technology catches up? While listening, I kept thinking: Can card products actually move at that pace, and can they afford to trade off perfection? ![Image of a slide comparing what is it like to ship a card product vs an AI product including timeline, key steps, systems involved, customer experience, and change cycles.](https://www.productftw.com/content/images/2026/05/card-vs-ai-shipping.jpg) Asked AI to make a photo about why card products can’t ship like AI products… and it shipped in 12 seconds. 💀 # Where this breaks in cards In AI, there is a growing acceptance that you can ship before everything is fully polished. You can build products that do not yet fully work and iterate as the technology improves. In card products, I think that tradeoff is more nuanced. Parts of that model translate well. Engineers can move faster with AI. Problem identification is faster. User feedback loops are faster. Alignment across product and engineering can be faster. A lot of the operational overhead, such as writing tickets or summarizing research, can be streamlined. You can absolutely move faster and accept imperfection in certain areas. Performance might not be perfect. Edge cases might not all be covered. The UI might not be fully polished. Those are acceptable trade-offs *if they do not impact trust or violate regulations*. What you cannot risk is correctness and clarity. Core flows need to work. A user needs to be able to repay their card. Interest needs to be calculated correctly. Disclosures need to be clear and accurate. Anything that touches money movement, fairness, or user understanding has a much lower tolerance for imperfection. So the question is not whether cards can move fast. It is where you can afford to be imperfect and where you cannot. # The Compliance Bottleneck 📝 Quick disclaimer before we go further: I am not in compliance. This is coming from building fintech products and learning where things get flagged, not from writing the rules myself. This is about product decisions and tradeoffs. **This is not legal advice.* In fintech, especially in card programs, most meaningful changes must pass through internal controls and external oversight before going live. If you are changing something users actually feel, there is a good chance it needs review. That could be internal compliance, risk, or approval by the sponsor bank or partner. Even small changes can raise questions about language, disclosures, fairness, or user impact. Someone has to read or interact with what you plan to ship and decide whether it introduces risk or misleads the user. There are exceptions. If you are adding something adjacent to the core financial product, you can often move quickly. A new feature that sits alongside the card or account experience is usually cleaner. Once you are inside core flows, the constraints tighten quickly. These constraints create a structural bottleneck. Teams can speed up everything leading up to a release, but the final steps still depend on human review. I do not think that will disappear anytime soon. These are decisions that require interpretation and judgment. AI will help, but, in my experience, full automation feels far off. The result is a growing mismatch. Product and engineering can generate more ideas, test more concepts, and prepare more changes than ever before. Compliance and partner review cannot scale at the same rate. The backlog builds and the system slows down at the exact point where speed matters most. # What do you do about it? One shift is toward fewer, higher-confidence bets. If review is the constraint, it does not make sense to flood the system with low-signal ideas. The bar for what gets pushed forward should be higher, not lower. Another shift is investing more in pre-alignment. The fastest teams in fintech are not skipping compliance. They are bringing compliance in earlier. They are shaping ideas with the constraints in mind, rather than treating review as a final step. This reduces rework and shortens the path to approval. This is also where product taste becomes more important, not less. # What product taste actually means in fintech Back to Lenny’s podcast: Cat talked about product taste in a way that is worth unpacking. At a high level, “product taste” is knowing what the right user experience should be, what feels most intuitive and delightful, and how to sort through a long list of requests to decide what is actually worth building. It is also about seeing patterns in how people use or even abuse your product today, and applying that information to shape what the product should become over time. That framing resonated with me because it matches what I have seen in strong PMs. They can look at a messy set of inputs and quickly identify what matters. They make good calls on what to prioritize, how to build it, and how it should feel for the user. They are not just executing. In fintech, I think product taste has an additional dimension. Good fintech PMs don’t just know about what is best for the user. They also understand regulatory boundaries and decide whether a bet is worth taking within those constraints. Good taste includes knowing when something is likely to get flagged, when it is worth pushing anyway, and when to reframe the solution entirely so the product can actually ship. These skills are hard to teach and even harder to measure. It feels less like a checklist and more like a compass. When everything is ambiguous, product taste points you toward the right call. One thing I found interesting is that teams like Claude Code are not framing AI as a way to reduce headcount. They are using it to raise the bar. Even as AI automates more of the day-to-day work, product does not become less important. It becomes more important. You still need to define who you are building for, which problem actually matters, and which highest-value use cases are. AI can help you execute faster, but it does not decide what is worth building. If anything, the role shifts further toward judgment. *When the cost of building goes down, the cost of building the wrong thing goes up.* That is where strong product thinking shows up. Product taste is about PMs making better decisions in a world where you can move faster than ever. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Flexibility vs. Maintainability - ProductFTW #79 URL: https://www.productftw.com/productftw-79-flexibility-vs-maintainability/ Last updated: 2026-05-10T23:41:12.000Z A common challenge in developing new technology is choosing between ultimate flexibility for users and your product team's ability to maintain that application. On the one hand, you allow users to set up and configure your app however they want, covering as many use cases as possible. On the other, you’re asking your engineers to maintain every possible configuration through the lifetime of that product. # People > Computers In practice, **most people are more flexible than computers**. (Take a second to let that sink in because I know it looks like a typo. It’s not.) Companies spend hundreds of millions of dollars customizing enterprise resource management platforms like SAP to match their company's very particular workflow. I consider these fools' errands. In reality, the better path is for a company to build a well-researched, well-developed workflow and develop a strong product opinion. (See [ProductFTW #23](https://www.productftw.com/productftw-23-opinionated-product/).) When you launch the product, you say, “This is a great way to do it, and we encourage you to retrain your team accordingly.” It sounds counterintuitive to ask people to flex to the software, but the reality is that most people don't spend time thinking about optimizing their workflow. They just start working. I learned this lesson early in my career while working as a consultant at Deloitte, even though technology wasn't really our business at the time. I worked on a project for a large utility company, helping their real estate department consolidate process flows. Utilities, not surprisingly, have a lot of real estate. They own properties, hold access easements for power lines, gas lines, water lines, and so on. We were looking across this real estate division, which had five different departments, and helping them simplify their business processes. This project was straight out of Consulting 101\. As a junior analyst, I mapped these processes using a specific piece of software (whose name I have since forgotten) to determine how to consolidate and improve them. One process that stands out to me now is accounts payable. You would think this is pretty basic: someone sends you a bill -> someone reviews it against a purchase order or budget -> it gets initially approved -> a later approver signs off -> it gets sent for payment -> payment is released -> process complete. Seems easy. Yet within this company, just in this real estate division, there were five departments, each with a different way of handling accounts payable. I can't imagine what it looked like across the entire organization. I remember very vividly sitting in a conference room, projecting my screen onto the wall, using specialized process management software, watching a couple dozen people arguing about which arrows should connect to which boxes. In the end, it taught me that it would have been better for someone to simply say: "I've looked at all five of your processes. I've identified the problems, the opportunities, and the legal and management requirements. This is how it should be done. Now, everyone go do it.” I don't know why it became an argumentative democracy. It's just accounts payable. (Please don’t forward this to your AP person so they can yell at me.) ![Anime-style illustration of a calm, sunlit yoga studio with wooden floors and neutral walls. A single woman balances in eagle pose on a purple yoga mat, arms and legs wrapped, focused and steady. Nearby, a laptop sits open on its own matching mat, angled as if participating in the session. A potted plant and a large window with green foliage outside add to the peaceful, minimalist atmosphere.](https://www.productftw.com/content/images/2026/04/flexibility-is-key-small.png) # Human Brains > Computer Software The same kind of thing applies to software. We all want software that works exactly like our brains, but we can train ourselves to use other tools in ways software cannot. There is some level of flexibility you can build into the software, but every time you do, you reduce your ability to maintain and understand the product. For product managers, a funny illustration of this is task management tools. Whether it's Jira, Asana, Trello, or now Linear, there's always a new interesting task manager coming out. (See [*ProductFTW #43*](https://www.productftw.com/productftw-xx-choosing-a-task-management-tool-as-a-product-manager/) for [Ellen](https://www.productftw.com/author/ellen/)’s take.) Personally, I can't stand Jira. I used to joke that the problem with Jira was that it was too configurable, and you could tell because companies had Jira administrators. When I worked at AT&T Interactive, there were around 400 engineers and three people who basically managed the Jira instance, which is absurd. Different teams had different flows and processes, and while that has some value (for example, a mobile deployment team does need a different process than a backend services team), it was way too complicated. You couldn't jump from Team A to Team B and understand what was going on. We use Linear at Totavi today, as many of our clients do. It's a great modern tool, and the Linear team has strong opinions. There are certain things they simply say no to, and I applaud them for it. Saying no is a critical part of product. (See *ProductFTW* [*#6*](https://www.productftw.com/productftw-6-how-to-effectively-communicate-as-a-product-manager/)*,* [*#7*](https://www.productftw.com/productftw-7-building-confidence-in-saying-no/)*,* [*#23*](https://www.productftw.com/productftw-23-opinionated-product/)*,* and [*#65*](https://www.productftw.com/productftw-65-sticking-to-your-vision/).) One thing they do let you customize is ticket states: you can define how many there are and what they are. That's a simple customization because, from a software perspective, you're just defining an ordered list. If, instead, you asked for sub-sub-statuses that lead to other statuses, you'd get increasingly complex control flows. Then, when you want to build something new, such as a mobile app alongside your web application, you have to figure out how to display all this data. It just gets more and more complicated. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # Flexibility = Lazy Strategy I actually think extreme flexibility is a sign of laziness in product strategy. You're essentially saying, "I don't know how this is supposed to work, so I'll try to make it work for everyone." It's often the result of companies that build products for larger customers, say a company with 20 or 40 customers, rather than 20,000 or 40,000\. When you have a noisy mass of consumers, each paying $5 a month, it's easy to stay focused. When you have 40 customers each paying $10,000 a year, it's very hard to ignore any one of them. However, as you grow and scale, the cost becomes enormous. A company I worked with a few years ago demonstrated this: a quarter of their product and engineering staff was dedicated solely to keeping the app running day-to-day, due to the complexity and customization they had accumulated. That's a very high number of people who aren't building new features or driving the business forward, but instead propping it up and keeping it from falling over. All of this speaks to why product leaders need to have strong opinions, grounded in consistent user research and a clear sense of who needs to be served. The Pareto principle, aka the 80-20 rule, is a great tool here. When I was at Green Dot, we conducted in-depth research on our users and identified 86 distinct reasons people used our cards. Three of those reasons accounted for more than 80% of users' responses. Those three reasons were the messages we pounded in marketing and the areas we focused on in product. If someone wanted to use the product for reason number 82, they certainly could. We also weren't going to explicitly support it or worry about it, because with limited resources, it would have been a distraction. # Flexibility = Maintenance = Costs Even today, in the age of AI, when we think building and customizing software will be easier, there is a long-term cost that I don't think people are paying enough attention to. **Custom software still has to be maintained.** If you allow your team to customize everything for individual users, and that one user leaves, what do you do with the next user? It remains critical for product managers to think through who their users are, what the best path is, and how to teach users to use the product intuitively without making everything overly flexible. Focus on maintainability and opinion rather than pure flexibility. # **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### There Is No Such Thing as a Good Deal on Dev - ProductFTW #78 URL: https://www.productftw.com/productftw-78-there-is-no-such-thing-as-a-good-deal-on-dev/ Last updated: 2026-05-10T23:41:11.000Z I’m not an engineer. I’ve never been a developer, and I don’t try to pretend otherwise. As a product manager, I work closely with engineers every day, and after a while, you start to notice the same patterns repeating. One of the most common ones is this: someone tries to save money on development. It usually comes from a good place. People think they are being efficient or practical. They look for the cheapest option, figuring that as long as someone can write code and ship it, that is enough. They question why they should pay for senior talent when they can hire junior engineers or lean on AI for much less. 🗒️ Before going further, it is worth clarifying something. **Product management is not a command and control role.* I do not tell engineers what to do. My job is to influence, collaborate, remove blockers, and bring clarity so the team can do good work. If the team does well, I do well. **This perspective is not based on authority.* It comes from observing how teams actually function. I see what breaks, where the pressure builds, and how often junior engineers are expected to perform at a level they have not reached yet. # You Get What You Pay For Most teams want to move faster while spending less. Those goals are in tension with each other. You do not get low cost, speed, and high quality at the same time. (see [*ProductFTW #62*](https://www.productftw.com/productftw-62-good-fast-cheap/)). If you hire junior engineers primarily to reduce cost, the tradeoffs show up quickly. The codebase becomes harder to maintain. Pull request reviews start to pile up. Quality assurance becomes more difficult. Overall velocity slows down instead of improving. Senior engineers spend more time reviewing and correcting work. The product begins to feel inconsistent. This is not a failure of junior engineers. It is a mismatch between expectations and reality. Junior developers need support, guidance, and time to grow. If those things are missing, they are set up to struggle. The worst part is, you might not even notice the damage at first. The shortcuts don’t always show up right away. They compound over time. You start to accumulate tech debt you don’t understand. Bugs sneak into edge cases. Scaling breaks. It’s a slow bleed, and then a crisis. # Junior Devs Deserve Better If you’ve made the call to hire junior engineers, that’s fine. Everyone starts somewhere. Junior engineers can be amazing. They bring fresh energy, curiosity, and a willingness to learn. I love working with them. The issue is expecting them to operate without support. You cannot hand them vague tickets and expect them to fill in the gaps. You cannot provide unclear product requirements and expect perfect outcomes. You cannot become frustrated when they ask questions or overlook details. When you hire junior talent, you take on additional responsibility. Requirements need to be more specific. Quality assurance needs to be more thorough. Communication needs to be more detailed. Patience is required. In most cases, a senior engineer should be involved to review work and help guide development. If you cannot support that structure, then you are not in a position to hire junior engineers effectively. ![Anime-style illustration of focused babies working in an office cubicle environment, typing code on laptops with serious expressions, surrounded by programming books, coffee mugs, and humorous tech-themed notes and posters.](https://www.productftw.com/content/images/2026/04/baby-devs.png) # Set the Right Expectations Here’s the big point: You have to be realistic. This ultimately comes down to expectations. There is no scenario where you get high quality, low cost, and fast delivery without tradeoffs. You are always exchanging time, money, or experience. If you choose to hire junior engineers, your plan needs to reflect that decision. Work should be broken into smaller pieces. Requirements should be more explicit. Timelines should allow for a slower pace. Additional time should be allocated for testing. Learning and mentorship should be part of the process. If those adjustments are not made, the outcome should not be surprising. # AI Is Not the Shortcut You Think It Is I also want to bring up the other “solution” I keep hearing about: AI. Let’s just have the junior devs use ChatGPT. Let’s lean into GitHub Copilot. Let’s automate the repetitive stuff. Let’s use AI as a force multiplier. Let’s go faster. Sure, I’m all for tools that make developers more productive. Copilot is amazing. ChatGPT is a great assistant. Let’s not pretend these things can write production-ready software without oversight. They hallucinate. They miss context. They take bad shortcuts unless they’re prompted very precisely. You need someone who understands how to *use* these tools well. Someone who can catch when they’re wrong. Someone who knows what “good” looks like. Expecting a junior engineer to also act as an expert in prompting, reviewing, debugging, and system design is not realistic. *AI tends to amplify the level of experience already present on a team rather than replace it.* It is also important to be clear about the current state of these tools. They are powerful, but they are not reasoning systems. They generate outputs based on patterns, which means they can be helpful in some cases and unreliable in others. # Final Thought Underpaying and overloading developers is not an effective strategy. Skipping mentorship and relying on tools to compensate for lack of experience does not lead to efficiency. Trying to avoid paying for experience usually shifts the cost elsewhere. In most cases, that cost appears later and is significantly higher when it does. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### You Don't Have a Roadmap Problem. You Have a Problem-Definition Problem. - ProductFTW #77 URL: https://www.productftw.com/productftw-77-you-dont-have-a-roadmap-problem-you-have-a-problem-definition-problem/ Last updated: 2026-05-22T02:26:18.000Z More than once, a company has hired us to help build its product roadmap. They knew the feature list they wanted to build, thoughts on who could help them build it, and even a rough idea of the economics. What they couldn't tell us was *why*. ## The Pattern Here's how these engagements generally started. The founder handed us a detailed feature list, asked us to help prioritize and sequence it, and to identify the right partners and tools to execute it. Straightforward consulting work, or so it seemed. We started asking our usual questions. For each feature: - Why this? - Who is it for? - What problem does it solve for them? The answers kept coming back to the same place: - "Competitors charge for this." - "We think we can monetize this." - "X company does this, and they're growing." Every justification was rooted in revenue or competitive positioning rather than specific user problems. Not because the founder was careless or inexperienced. In fact, the opposite has been true. These founders knew their industry deeply, had strong domain expertise, and understood the economics of the space. However, that expertise was pulling them toward solutions before they had clearly defined the problems those solutions were meant to address. They had jumped from "I have a vision" to "Let's pick partners and start building" without the critical middle step of defining the problem that needs to be solved and for whom. ![](https://www.productftw.com/content/images/2026/04/product-roadmap-2.jpg) ## Why This Happens When you know a space well, it feels natural to skip the discovery phase. You already know what the market looks like and what competitors offer. The problem is that knowing the industry is not the same as *knowing your users*. Industry knowledge tells you what exists. User knowledge tells you what's missing, what's broken, and what people are actually struggling with day to day. There's also a pull toward revenue-based reasoning. "We can charge $X per month for this feature" sounds like a business case, but *revenue is an outcome, not a reason*. If the feature solves a real, painful problem, the revenue will follow. If it doesn't, no amount of pricing strategy will make users care about it. One particular example of this pattern stands out. A client insisted on adding financial services to their platform because they saw revenue potential. They skipped discovery entirely and when they launched, their users didn't trust the new features. A new KYC process was rolled out to enable the new features, but it felt invasive and users didn't understand why the platform was suddenly asking for their financial information. On top of that, the features took an old-school, in-person B2B payment process, modernized it, and made it digital. It turned out that their users liked the in-person process because it was an opportunity to interact with their customers, and they didn’t want to lose that touchpoint. The features went unused and the revenue never materialized. The lesson from that engagement was clear: *you cannot monetize a problem that your users don't have.* This isn’t just a startup problem, though. Facebook made the same mistake when it launched Libra in 2019\. I’m sure the business case seemed very compelling. There were billions of users already on the platform, so if Facebook could tap into their wallets, there was tons of revenue potential. They skipped the most important question of whether their users actually wanted Facebook to handle their money. The answer was no. After several attempts to make it work, including a couple of rebrands and a shift in strategy from a multi-currency coin to a stablecoin, the project was sold for parts in 2022 and then collapsed a year later. Compare that to Starbucks Rewards and the Starbucks app, which have been wildly successful. Starbucks solved two problems for its users: waiting in line and fumbling with payment. The app lets people order ahead, pay from their phone, and earn rewards for something they were already doing. The financial layer made an existing habit faster and more rewarding. Today, rewards members account for over half of Starbucks’ US revenue. ## The Deeper Issue: You Can't Prioritize Without Problems Another consequence of trying to build a roadmap based on revenue assumptions rather than user problems is that you lose the ability to prioritize. When someone asks us to help them sequence a roadmap, we need a basis for deciding what comes first. That basis has to be grounded in something real. Specifically, it comes down to two questions: *How painful is this problem, and how many of your target users experience it?* When every feature's justification is "we think we can charge for it" or "competitor X has it," you've lost that decision-making framework, and everything looks equally important. There's no way to distinguish between a feature that will drive adoption and one that will sit in a menu untouched. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## How We Reset the Roadmap When we see this pattern, we don't start by rearranging the feature list. We roll back the conversation to the step that was skipped. The first thing we do is understand the people who will actually use the product. We start with the classic product exercise of defining personas or actors to make sure we understand who a company’s customers are, and then map features to each persona. From there, we ask "why" and refuse to accept revenue as the answer. The questions we always drive toward answering are: Which specific user problem does this solve, and how do we know that problem exists? This is where a founder's domain knowledge becomes so valuable. They usually know the pain points from years of industry experience, they just haven't connected those pain points to the features on the list in any structured way, or they’ve overindexed on how they would like to do something, when they themselves might not actually represent their user base. Once we understand all of this, some features get sharper and more urgent, while others fall away. A feature might sound exciting, but when you examine it closely, the actual user problem it addresses is marginal. Maybe the pain is real, but it affects so few users that it doesn't justify the engineering investment. *Revenue upside alone can't answer those questions, but problem definition can.* After we've done this work, prioritization becomes more straightforward. The features that address the most painful, most frequent user problems go to the top. Features that are nice to have or address marginal problems go to the bottom. None of this means revenue is irrelevant. It means that *revenue, as a validation point, comes later in the process.* The order matters: 1. Is there a real problem? 2. How big is it, and how many users does it affect? 3. Will solving this problem pay for itself or justify the investment, whether through direct revenue, reduced churn, lower support costs, or protecting the company's reputation? Revenue is still a key consideration, but it’s just not the one driving the conversation before we've answered the first two questions. The resulting roadmap usually looks very different from the one the founder walked in with. Not because the features changed, but because the ordering now reflects what users actually need instead of what the company hopes to charge for. ## The Test If you're reading this and wondering whether your own roadmap has the same issue, here's a simple test. Pick any feature on your roadmap and try to complete this sentence: > "We are building \[feature\] because \[specific user\] currently struggles with \[specific problem\], and we know this because \[evidence\]." If you can fill in every blank with confidence, you're in good shape. If the best you can do is "we are building this because competitors have it" or "we are building this because we think we can charge for it," you don't have a roadmap problem. You have a problem definition problem. # **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Decisions Without Context Don’t Scale - ProductFTW #76 URL: https://www.productftw.com/productftw-76-decisions-without-context-dont-scale/ Last updated: 2026-05-22T02:26:31.000Z 🖇️ Did someone forward this to you? [Subscribe to ProductFTW today.](https://www.cardsftw.com/?ref=productftw.com) We have all been there. It is late in the sprint, engineering is wrapping up, QA is testing, release notes are ready, and the team is moving toward the finish line. Then something happens, like last-minute stakeholder feedback, and the release slips. From the outside, these delays almost always get blamed on engineering. We have all sat through retros trying to explain what went wrong. Over time, a pattern starts to emerge. Many delays do not originate in engineering. They start earlier, with product indecision. ![Image of a woman with caption "It's me. Hi, I'm the problem, it's me."](https://www.productftw.com/content/images/2026/04/anti-hero-lyrics.png) Do engineers think of product managers as the ultimate anti-heroes? This is not to say every delay is a product problem. Unexpected issues do happen. The point is that product has more influence here than we’d like to admit. When your decisions are unclear or revisited too late, the impact shows up at the end of the sprint. # Where delays actually start A lot of delays come from decisions that were never fully made or never clearly documented. This has happened to me. I was building a new onboarding flow for a credit card. During design, someone suggested adding a save and return later feature. It sounded like a great idea and a reasonable improvement for users. As we dug in, we noticed that many competitors do not offer this feature in their application flows. The complexity started to become clear. Saving drafts would require storing sensitive personal data before an application is complete. That introduces additional security risk, expands compliance scope, and creates more operational overhead. I made a straightforward decision: we were not going to support draft saving. Users need to complete the application in a single session and, if they drop off, they start over. The tradeoffs were clear and I documented the decision. # What happens without decision clarity A few months later, as we were approaching launch, I did a demo for stakeholders and someone immediately asked whether a save feature should be added. I had documented the decision months prior, so the response was straightforward. The team already evaluated this as a feature and made a conscious tradeoff decision. Unless something materially changed, the decision would stand and the team continued forward. I’ve also been in the position where I didn’t document a decision, and that's when things start to unravel. When you can’t recall why the team said no, no one is fully confident and the discussion is reopened. Design may start revisiting flows while engineering evaluates the new scope, and QA may need to consider new test cases. A single question can turn into real work across the team and it always happens at the worst possible time. # Tips and Tricks There are a few practices I consistently rely on to reduce indecision and rework. - I keep a decision log. Nothing fancy. Just the decision, the rationale, and the date. I cannot tell you how many times I have gone back to it when someone asks, “Why did we do it this way?" - I make sure my meeting notes capture outcomes and context, not just what people say. A decision without context is not that useful. I always think about what will be most useful to me when I come back to it a few months later. If all I see is “we decided not to include the save button,” I will have no idea what that actually refers to or why we made that call. Without context, it is almost guaranteed that we will question it or revisit the decision. - I write product briefs that explicitly call out what we are not doing. This part matters more than people think. When something is intentionally excluded, I want it written down so it does not creep back in later. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. 💫 ****A quick note on perfectionism** One thing I've learned to look out for is perfectionism. Sometimes the delay is not confusion or a lack of documentation. Sometimes it is me wanting to get everything exactly right before we ship. I have caught myself trying to account for every edge case or revisiting small details that are not actually blocking the core experience. In those moments, I have to ask whether I am improving the product or just slowing the team down. In many cases, the extra time does not lead to better outcomes. It just delays getting the product in front of users and pushes the timeline without adding real value. # How I stay on track When things feel messy, I try to fall back on a simple framework to keep myself grounded. - I set decision deadlines so things do not stay open forever. If a decision is made, I treat it as final unless new information comes in. Opinions alone are not enough to reopen it. - I write the rationale every time, even if it is just a few sentences. I know I will forget the context later, and someone else definitely will. - I make a point to communicate decisions clearly so no one is surprised down the line. - I keep coming back to the core user problem. If a discussion does not clearly connect to that, it usually is not worth the time. - Lastly, when I am unsure, I default to shipping the simpler version. I would rather learn from real users than keep guessing internally. (Read more about the simple version in [*ProductFTW #61*](https://www.productftw.com/productftw-61-the-mvp/).) Sometimes a delay really is an engineering problem, but if it keeps happening, take a look at your product decisions upstream. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Words Matter - ProductFTW #75 URL: https://www.productftw.com/productftw-75-words-matter/ Last updated: 2026-05-10T23:41:08.000Z 🖇️ Did someone forward this to you? [Subscribe to ProductFTW today.](https://www.cardsftw.com/?ref=productftw.com) Picture this: You're on a launch planning call with your bank, your processor, and your internal team. Someone says "We'll be ready for alpha." Someone else says, "I thought this was beta." A third person asks, "So is this the friends and family launch?" The bank calls the initial limited rollout "alpha" because you’re creating accounts in production for the first time. The processor calls the same phase "beta" because their alpha was the production setup and backend testing. Your internal team calls it "friends and family" because that's a common industry name for a first rollout. Nobody is wrong; you’re also not fully aligned. ![Chart of words with different organizations using different words to mean the same thing.](https://www.productftw.com/content/images/2026/03/ProductFTW--75.png) **If only launch plans felt as simple as this graphic looks.* Same launch. Three names. Suddenly, the conversation isn't about launch planning anymore, it's about translating vocabulary. This is a small example of something I think about a lot as a product manager: language discipline. When people use different words for the same thing (or the same words for different things), the consequences can impact timelines, development, and trust between partners. Much of product work comes down to building shared understanding, and shared understanding is built (or broken) in the words we use. ## **Where It Gets Risky** In card programs, one of the places I see this frequently pop up is in flows of funds, especially around account naming and account structure. This is where language misalignment stops being mildly annoying and starts creating risk. A warehouse lender, a program manager, and an issuing bank may all have requirements around where different types of funds are held and how they're allowed to move. Each party often shows up with a slightly different flow, different account naming conventions, and a different mental model of what each account is for. On the surface, the diagrams from each party can look very similar, but minor differences may reflect meaningful disagreements about control, obligations, or legal structure. Without someone driving consistency in naming, the conversation gets bogged down defining things instead of resolving actual issues. This seems to happen often at exactly the point the program is trying to move fast to get to launch. In practice, that means someone (product) needs to create a unified flow that shows where each party's version aligns and where it doesn't. ## **Building the Translation Layer** External parties are not going to adopt your terminology, or each other’s, *and that's fine*. The question is whether your team has a shared, written understanding of where the vocabulary overlaps and where it diverges, or whether that context only lives in the heads of a couple of people who've been on every call. Product's job is to build the translation layer. That means asking partners early on in the process what they mean by terms you haven't heard before, getting ahead of common places where misalignments can happen, and flagging them out loud when they inevitably do. That usually means being the person in the room who says "Just to make sure everyone's on the same page…" and then providing the clarity that's needed. Also crucial: writing this clarification down somewhere everyone can actually find it. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **How to Build the Habit** ### **Anticipate where language will break**. While some of the examples above are specific to card programs, every project, whether cross-organizational or not, has communication weak spots. It can be phase names, status definitions, or even something as seemingly-simple as what “ready” or “done” means. Take note of where you see these happening on your projects so you can get ahead of them in the future. ### **Make sure everyone is aligned, and note where others use different terminology.** Often it's as simple as, "When you say X, what do you mean?" or, "Just to confirm, are we talking about Y?" If you're concerned that people will think you don't know what you're doing, be clear about your intent: "Thanks. I want to make sure my team knows what your team means so we can work together more effectively." Those small interventions clear things up in the moment, and over time they build a team culture where checking for alignment is normal, not awkward. ### **Document, document, document.** A simple table that maps your team’s terms to your partners’ terms is enough. The point is that the translation layer can’t live in your head and it has to be accessible to anyone on the team, especially the people who aren’t on every call. ### **Share it.** Put that table you made where people will actually look for it. Where exactly that is depends on your team. The best place might be in your project wiki, pinned in your Slack channel, or linked in your status docs. Wherever that place might be, make sure it’s there because a glossary nobody can find is the same as no glossary at all. The key is to treat language not as a side concern, but as part of how product work gets done well. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.Same launch. Three names. Suddenly, the conversation isn't about launch planning anymore. It's now about translating vocabulary. ### How to Thrive as a Product Manager When the Product Already Exists - ProductFTW #74 URL: https://www.productftw.com/productftw-74-how-to-thrive-as-a-product-manager-when-the-product-already-exists/ Last updated: 2026-05-22T02:07:36.000Z 🖇️ Did someone forward this to you? [Subscribe to ProductFTW today.](https://www.productftw.com/) We have spent a lot of time on this newsletter talking about the experience of being the first product manager at a startup. [Zach covered that firsthand](https://www.productftw.com/productftw-4-being-the-first-product-manager/), and it is worth reading if you are in that seat. Today I want to focus on something different: what you should do when you join a startup after the product is already live. To frame this, I think about product management skills in two buckets. The first is 0 to 1, which is the work of turning an idea into something that exists. The second is 1+, which is taking something that already exists and pushing it forward. These require genuinely different skills, and not every product manager can do both well. I will be honest: I gravitate toward 0 to 1\. There is something about starting with a blank canvas and seeing it through to something real that feels like being an artist. You get to make every creative decision, watch the thing take shape, and learn an enormous amount in a compressed period of time. I love that kind of accelerated learning. That said, I do enjoy 1+ work too, and I think it is where many PMs actually thrive. The challenge with 1+ is the urge to come in and immediately do things “your way.” You look at what exists, and you see all the things you would have done differently. I have felt this myself and heard about it from many others. *You must resist this urge.* A better approach is to first solidify your understanding, meet your goals within the existing structure, and then shape the product into something new over time as you build trust and learn context. ![An illustrated, Studio Ghibli–style scene of a man sitting at a wooden table with his head resting on his hand, looking thoughtfully at two metal buckets in front of him. One bucket is labeled “0-1” and the other “1+.” The background shows a cozy indoor setting with warm tones and a bookshelf, emphasizing a contemplative, decision-making moment.](https://www.productftw.com/content/images/2026/03/PM-types-1.png) Hands are hard for all artists, even AI. If you are not sure which PM-skills bucket you prefer, ask yourself a few questions: - Can you create something out of nothing? - Can you see a path that no one else seems to see yet? - Do you understand what it takes to build new software from scratch? - Do you know how to validate an idea through signals when there are no users yet? If you answered no to most of those, you are likely wired to be a strong 1+ product manager. (Yes, I made up this "1+" terminology. It is how my brain organizes the work, and I find it useful, so we are going with it.) ## Start by building a complete picture When you join a company in the 1+ phase, your first task is not to build anything. Your number-one priority is to understand what already exists and why. What did they build? How are they measuring success? What decisions were made along the way, and why were they made that way? You are going to spend a lot of time in conversations with your coworkers in those first weeks, piecing together a snapshot of where the product is right now. Ideally, you already have some of this context from your interview process. You should know roughly why they hired you and what they expect you to do. If your goal is something vague like "get more users," that ambiguity is a signal to push for clarity early, and, honestly, it is something you should ask about before you accept the offer. "How will I be evaluated in my first 90 days?" is a completely reasonable interview question, and the answer tells you a lot. Once you have the snapshot-version of the past, you can start identifying the levers that are actually available to you. This is where the 1+ role gets interesting. There was already a vision before you arrived. There was already a strategy. You were (probably) not hired to start over. Your role is to step into that momentum and drive it forward. To do that well, you need to understand the landscape clearly because you cannot move something you cannot see. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## Use the advantages you have Here is what is different about the 1+ that a 0-to-1 PM would love to have: you have real users. That is a significant asset, and one that many PMs do not lean on enough when they start a new role. Talk to your existing users. They will tell you things your internal data never will. Look for places where users are already sharing unsolicited feedback, which might be Reddit, app store reviews, comments, or anywhere people go to complain (rave) about products like yours. This kind of organic feedback is extremely useful, and it costs you nothing. At the same time, audit what data infrastructure actually exists. Do you have analytics on the product? Do you know where users are coming from? Has anyone ever talked to a customer? Is there a support channel, and if so, what patterns show up there? If the answer to most of these is no, you’ve now created a roadmap. Those gaps are exactly where you can start building the visibility you need to do your job. My career includes many stories like this. Much of my work involves joining a company in the middle of a significant transition, whether that is launching their first credit card program or replatforming an existing product, and trying to learn as much as possible while making the biggest impact in the shortest amount of time. What I have noticed across all these transitions is that an outside perspective is an advantage most internal PMs do not have. When you are close to a product every day, you stop seeing it the way a new user sees it. You stop questioning decisions that were made two years ago because they have just become the “way things are”. Coming in fresh, without that history, means you are actually in a better position to spot the gaps than the people who built it. The key is learning to use that perspective before it fades, because the longer you are inside a company, the more you start to see things the way everyone else does. ## Narrow down to the right lever Once you understand both the internal context and the external feedback landscape, you can start to get specific about what you are actually trying to move. Is the goal revenue? Conversion? Top of funnel growth? User retention? Something more ambiguous? Getting clear on the goal lets you work backward. If more users at the top of the funnel means more conversions downstream, then the question becomes: where is the friction? Where are people dropping off? Where are you hearing about pain points, and are those consistent across the channels you are now monitoring? You are looking for the place where a focused intervention can create a measurable result. The 1+ PM role is fundamentally about making a product that already works, work better for more people. You have context, users, and history to work with. The job is to use all of it. ## Now go do the work Laying the foundation is the unglamorous part of the 1+ role, and most PMs rush through it. If you have done it properly, you now know what the product is trying to accomplish, where the real friction lives, who your users are and what they are telling you, and which lever is most worth pulling right now. Many PMs operate for months without that clarity. Here is what thriving actually looks like: - Pick one goal and go deep on it before you touch anything else. - Talk to at least five users before you write a single requirement. - Build a relationship with your data by knowing what you are measuring, trusting it is accurate, and checking it regularly. - Communicate with stakeholders about what you are learning and why it is shaping your priorities. - When you feel the urge to recreate something that is working just fine because it is not how you would have built it, pause and ask yourself whether changing it actually moves your goal forward or if you are just redecorating. The PMs who thrive in 1+ roles are not the ones who come in with the loudest opinions about what should change. They are the ones who earn trust quickly, move a number that matters, and build enough credibility that when they do want to make changes, people are ready to follow them. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### When Should Your Startup Hire a Head of Product? - ProductFTW #73 URL: https://www.productftw.com/productftw-73-when-should-your-startup-hire-a-head-of-product/ Last updated: 2026-10-14T01:25:34.000Z 🖇️ Did someone forward this to you? [Subscribe to ProductFTW today.](https://www.productftw.com/) As a follow-up to [*ProductFTW #70, Do Startups Need Product Managers?*](https://www.productftw.com/productftw-70-do-startups-need-product-managers/), I was asked: when should a startup hire a head of product? I wrote about this topic years ago on my personal blog in [*Startups and Heads of Product*](https://www.matthewgoldman.com/startups-and-heads-of-product/?ref=productftw.com), but it was more pondering than prescriptive. Ellen made the case in #70 that startups "need to hire a Product Manager when misalignment starts costing real money." I made the case in my personal post that you can hire a head of product on day one. This disconnect leads to two key questions: - What exactly is a "head of product"? - When is a single PM not the head of product? As an aside, does anyone else find the title "head of" to be quite amusing? According to my research assistant Claude, the shift from traditional "VP" titles to "head of" titles occurred in the 2008-2015 era, driven by a push for flatter organizations (à la Zappos) and greater title flexibility. Clearly, a future post is in the making on Head of Product vs. CPO. In startups without a Chief Product Officer, the Head of Product is the de facto leader of the product organization. This person is responsible for leading the product team, organizing the product roadmap, and ensuring that product management processes are followed. ![Office hallway with a wood door at the end. The door has a window and on the window is a sign reading "head of product."](https://www.productftw.com/content/images/2026/03/Head-of-product-office-door.png) So if a startup has only a single PM, are they not, logically, the head of product? Well, yes and no. In a small startup — especially one without a CEO with a product background — the PM is typically responsible for the day-to-day product work: developing requirements, collaborating with engineering, and so on. In that sense, they share some responsibilities with a head of product. But at this stage, the CEO typically owns the roadmap itself. The PM is more of an execution-focused resource than a strategic one. When a company needs a head of product isn't simply a matter of funding stage (people often ask me: is it Series A? Series B?), but of the size and complexity of the product and organization. What does Series A mean anymore anyway? Marketing has driven a long slide in the definition of equity rounds. While Series A used to denote the first institutionally-backed venture capital round, typically around $5MM, we now have Series Seed, Pre-Seed, and probably soon something like Series Just an Idea. If I raise VC again, I want to convince my investors to let me start at Series Z and work backwards. With ongoing changes in product development driven by LLMs, it's genuinely unclear how these roles will evolve. Traditionally, I would have said that once a company has at least three or four product development teams (pods, squads, whatever you call them), you start to need a head of product. In that construct, the head of product looks a lot like a Group PM at a larger company: responsible for managing a small team of individual contributor PMs, aligning cross-team interactions, ensuring consistency in process and artifact development, and maintaining the roadmap. Note, I said *maintaining* the roadmap, not *owning* it; that probably still sits with the CEO. Maintenance means keeping it current, surfacing trade-offs, and connecting the dots across teams. If you have three or four squads, you likely have either a growing and complex product or more than one product line. That's the real inflection point. When a PM's scope is narrow (we just make this one app), it's easier to scale without adding a management layer. When does complexity typically demand it? Usually, when revenue exceeds $10MM annually, or fundraising is at Series B. OK, there's your answer. You'll often see the title appear earlier, because people love titles (even people who say they don't). We're social, status-driven creatures, and it matters. A strong PM who joins early may ask for and receive the "head of product" title over time, even if the role doesn't fully justify it yet. We hand out co-founder titles like CEO and CTO when there are only two people in the company, so it's nothing new. If you're weighing whether you need a head of product, focus more on specific responsibilities, team size, and product complexity than on the funding stage. A good leading indicator: when the product team starts to feel disconnected or uncoordinated, that's usually the right time to bring in someone who can manage it all. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Stop Hiring a Two-for-One Unicorn - ProductFTW #72 URL: https://www.productftw.com/stop-hiring-a-two-for-one-unicorn/ Last updated: 2026-05-22T02:07:31.000Z 👀 Did someone post this to Slack? Subscribe to ProductFTW and get insights sent directly to your inbox. Now that I’ve written a post about the difference between [product, program and project roles](https://www.productftw.com/productftw-69-project-product-program-managers-and-owners/), I’ve started to notice how many job postings blur the line between a product owner (PO) and a product manager (PM). Titles aside, what these companies actually want is both: someone who can get in the trenches with engineers and write pixel-perfect tickets and someone who can define the long-term product strategy, talk to users, and steer the roadmap. That’s not a product owner. That’s not a product manager. That’s a unicorn. If you’re lucky enough to find one, they’re going to be expensive. So how do you know which one you need? Ask yourself: - Am I struggling to define what to build and why it matters? - You need a product manager. - Do I have a clear roadmap, but struggle to move efficiently from idea to shipped product? - You need a product owner. - Am I early-stage and can’t afford both? - Fine, but know what you’re asking for. You need someone senior with experience in both, someone who is comfortable bouncing between tactics and strategy. Most importantly, you need to give them the support to do it all without burning out. If you’re not sure what your primary pain point is, you’re not ready to hire. Get clarity on where the bottleneck is. You don’t want to end up with someone great at roadmap planning who’s stuck chasing down tickets, or vice versa. ## **What Companies Think They Want** Let me describe the role I see posted over and over again. - Own the backlog - Run standups - QA new features - Write user stories and acceptance criteria - Be the voice of the customer - Define the product strategy - Conduct user research - Collaborate with design - Prioritize work against business goals - Report on KPIs - Align stakeholders In other words, be a PM, a PO, a designer, a researcher, a business analyst, a scrum master, and a QA tester all in one person. To be fair, this is often what early-stage startups need. They don’t have the headcount for separate roles. They need someone who can go deep and go wide. Someone who can write the tickets, manage delivery, and think big at the same time. Unfortunately, it’s not sustainable unless you find someone with two very different skill sets. Someone who knows how to timebox. Someone who doesn’t get overwhelmed when juggling competing priorities. Someone who is equally comfortable writing SQL and talking to customers. That person exists, but there aren’t many of them, and they aren’t cheap. ![Drawing of a white unicorn with a pastel rainbow mane sitting at a computer keyboard and monitor showing charts and graphs. The unicorn is surrounded by smiling people but it looks a little stressed.](https://www.productftw.com/content/images/2026/03/Unicorns-are-not-real.png) This unicorn is so stressed out, it is typing with a pen and drinking TWO cups of coffee. ## **What a Product Owner Does** Let’s be clear. A traditional product owner is a delivery role. It’s focused on execution. They live close to the engineering team, and their day-to-day is about translating ideas into buildable, testable chunks. Typical product owner responsibilities: - Maintain the backlog - Refine tickets - Write user stories and test cases - Make tradeoffs with engineering - Accept or reject completed work - Help with UAT and QA - Unblock devs They’re essential in organizations where the PM is more outward-facing. Especially when PMs don’t have the time or patience to get deep into implementation details. POs make sure the dev team keeps moving. They’re not usually doing customer interviews or prioritizing the roadmap based on business objectives. They’re focused on what’s next, not what’s next quarter. A good example of when a PO shines: an engineering team mid-sprint hits an ambiguous edge case in a transaction flow. Nobody knows what the expected behavior should be. The PO steps in, makes the call, updates the acceptance criteria, and the team keeps moving. They don’t pause to conduct a customer discovery session or update the strategy doc. They make a fast and informed decision so the sprint doesn't stall. ## **What a Product Manager Does** On the flip side, product managers are meant to own outcomes. They’re responsible for figuring out what to build, why it matters, and how to align it with user needs and business goals. Typical PM responsibilities: - Set product vision and goals - Define and manage the roadmap - Talk to users, stakeholders, and execs - Write product briefs - Define success metrics - Prioritize features based on impact - Work with design to shape the solution Can a PM write tickets and run standups? Absolutely. Many of us have done that, especially in small teams. Unfortunately, not every PM wants to do that, and not every PM is good at it. The bigger point is, it’s a different job. The skills that make someone a strong strategic thinker are not always the same ones that make them detail-obsessed and delivery-focused. A good example of when a PM shines: a new card program is seeing strong top-of-funnel interest, but applications aren't converting. A PM digs into the data, talks to users, and realizes people are abandoning the flow because they don't want to risk a hard pull on their credit if they're not confident they'll get approved. They write the brief, align leadership, and hand it off to design and engineering to build a pre-qualification flow. That's the main job, figuring out what's worth building and why. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## **The Two for One Trap** Here's the problem. If you're hiring for a product manager and you really want a PO-style delivery partner, you'll get someone who can help your dev team ship, but they probably won't help you define a long-term strategy. If you hire a PM and expect them to own the tickets too, you might get pushback, or worse, half-baked delivery work because they're focused on higher-level outcomes. A scenario that plays out more than people admit: a startup hires a strong strategic PM, someone with great instincts, sharp prioritization skills, and executive presence. Six months in, the engineering team is frustrated. Tickets are vague. Sprints are chaotic. The PM is doing brilliant roadmap work, but nobody has refined the backlog, and the devs are constantly waiting for clarity. The company assumes the PM is underperforming. In reality, they hired the wrong role for the problem they had. The reverse happens too. A company hires an execution-focused PO who is incredible at running clean sprints and keeping the team unblocked. A year in, leadership is frustrated because there's no clear product direction. Features are shipping, but there's no coherent strategy tying them together. Again, not a performance problem. A role definition problem. The two-for-one is a great deal if you can find the right person. Most people lean heavily toward one side. Either they're the planner and strategist type who can wrangle execs and define big bets, or they're the execution-focused doer who loves being on Slack with the engineering team all day, making sure tickets are airtight. Let's be real. Context switching between those modes is intense. It's not just task switching. It's brain switching. You go from writing a product strategy memo to hopping into Figma comments to catching a regression bug in staging. That's a lot of mental load. If you're not careful, you end up being mediocre at both jobs. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Why Rewards Timing Matters - ProductFTW #71 URL: https://www.productftw.com/productftw-71-why-rewards-timing-matters/ Last updated: 2026-06-04T19:27:29.000Z A few weeks ago, we wrote about [payment timing and why it is a product decision](https://www.productftw.com/productftw-68-credit-card-repayment-timing-is-a-product-decision/), not just an operational one. That post led to a bunch of side conversations internally about other timing decisions we make without always calling them product choices. The one that keeps coming up for me is rewards. When you are building a payment product with a rewards component, you spend a lot of time debating earn rates, bonus categories, partner offers, burn mechanics, and all the fun stuff. We will probably write more about designing a rewards system in later posts, but what I want to focus on here is simpler and more foundational: when rewards are attributed, when they are usable, and why those decisions matter more than people think. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## The sequencing of rewards Before getting into tradeoffs, let’s align on definitions. I think about rewards in three states: earned, available, and redeemed. Earned is when you make a transaction that qualifies for a reward, and you are granted points. They show up somewhere in the product. They exist in your balance. They are not yet usable. 💡 You may be thinking: isn't this just pending? Yes, most major issuers do use pending in their UX, but have you noticed that the term is typically limited to rewards-specific screens? That is intentional. Mixing pending with transaction states and business logic gets confusing fast. For example, a transaction can be pending (not yet settled) while points could be available for redemption. To keep things simple, I am using earned throughout this post. We are all product people here, and the goal is to make sure our requirements do not confuse developers. ![Screenshots from American Express, Coinbase, and Chase to demonstrate their "pending points" sections and tool tips.](https://www.productftw.com/content/images/2026/03/image-2.png) Available is when those points can actually be redeemed. This is the moment the user can apply them to a statement credit, convert them to cash, transfer them, or use them in whatever redemption flow you support. ![Screenshots from American Express, Coinbase, and Chase to demonstrate their "available points" sections and tool tips.](https://www.productftw.com/content/images/2026/03/Frame-32.png) Redeemed is exactly what it sounds like. The points have been used and are no longer available. ![](https://www.productftw.com/content/images/2026/03/image-1.png) These definitions are straightforward. The complexity comes from deciding when each of these states is triggered. Each trigger has a downstream impact on user experience, support load, fraud risk, accounting, and even marketing. ## When are points earned? The first decision is when to mark rewards as earned. One option is to attribute rewards immediately upon authorization of the transaction. This means the user spends and almost immediately sees how much they earned. Coinbase does this with BTC rewards. The feedback loop is tight and intuitive. I spend, and I see the reward. It reinforces the value proposition in real time. From a product standpoint, this is a great experience. It feels modern and transparent, and it helps users connect behavior to benefit. From an operations standpoint, it can be messy. Authorized transactions are not final. Tips get added, amounts can change, and transactions fall off. If you show rewards instantly and the underlying transaction adjusts before settlement, the reward number may need to change. When that happens, users assume something broke. Support ends up explaining settlement mechanics to people who do not care about settlement mechanics. The more traditional approach is to attribute rewards at settlement. At that point, the transaction amount is final, accounting is cleaner, and you avoid the tip adjustment problem. Your ledger aligns with your processor, and your finance team is happier. The downside is obvious. The user may wait a few days for the rewards to appear. The reinforcement loop is slower. If you are positioning your product as fast and delightful, this delay can feel out of sync with the rest of the experience. There is no universally correct answer. The right choice depends on what you are optimizing for and how much operational complexity you are willing to absorb. ## When do points become available? Earning is only the first layer. The second decision is when those earned points become available. You can make them available immediately upon settlement. You can batch them at the end of the settlement day. You can unlock them at the end of the statement period. Some programs add extra holding periods for specific categories or high-risk transactions. This decision is really about risk tolerance. Even settled purchases can be returned. Chargebacks happen. Fraud is sometimes detected days or weeks later. If you make points available immediately and the user redeems them, you may have to claw back value when the underlying transaction reverses. Clawbacks are painful. They create negative balances and confusing experiences. They also generate support tickets from users who feel like something was taken away from them. If you delay availability until the end of the statement cycle, you significantly reduce that risk. Returns and disputes often surface within that window. You gain time to reconcile before letting value leave the system. The tradeoff is that users see points sitting in their account that they cannot use yet. If that gap is not clearly explained, it feels arbitrary. Even if it is explained, the program can still feel less flexible. Some teams try to get more nuanced. They unlock low-risk transactions quickly and hold higher-risk ones longer. Others tie availability to risk scores. That approach can work, though it adds engineering and data complexity that not every team is ready for. ## How timing shapes perception What I find interesting is how much these timing decisions shape perception, even when the earn rate is identical. If rewards are earned and available instantly, the program feels generous and responsive. The reward feels embedded in the purchase itself. ‼️ Points being available instantly upon authorization is unheard of, though technically feasible. From a development standpoint, it does simplify the flow, which is appealing. Unfortunately, it also introduces significant risk. More on this below. If rewards are earned at settlement and only available at the end of a billing cycle, the program feels more like a periodic rebate. That model has worked for decades in credit cards. It just sets a different expectation. Clarity is more important than speed in most cases. If users understand that rewards will show up after settlement and unlock at the end of the statement period, frustration drops. Confusion usually comes from misalignment between what the user expects and what the system actually does. This is where product design has to do more than legal copy. Terms and conditions are necessary. The UI should clearly distinguish between earned, available, and redeemed. Transaction-level detail should explain why something is not yet usable. State should be visible and intuitive. When users can see what is happening and why, they are far more forgiving of delays. ## The financial and operational side Rewards are a liability. The moment points are earned, the program is accruing cost. The moment they are redeemed, that cost becomes real. Shifting the timing of earning and availability changes how that liability shows up on your balance sheet. If you accelerate earning and availability, you accelerate potential redemption. If your economics rely on breakage assumptions, timing changes can materially impact your forecasts. There is also fraud exposure. Instant availability can be exploited in edge cases, especially with merchant-funded rewards or category bonuses. Tight controls and clawback logic help. They rarely eliminate all risk. This is why I keep coming back to the idea that timing is a product decision. It touches risk, finance, operations, engineering, and support. It also directly shapes how users perceive the value of your program. ## Designing intentionally The best rewards programs are not necessarily defined by delivering rewards the fastest. They are the most coherent. The timing of earned, available, and redeemed aligns with the brand, the risk appetite, and the operational maturity of the company. If your product promise is speed and transparency, showing earned rewards instantly may be worth the operational friction. If your margins are thin and your scale is large, tighter controls and delayed availability may be the responsible choice. What matters is that you choose intentionally. Timing should not be inherited from your processor or copied blindly from a competitor. It should reflect your strategy and your constraints. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Do Startups Need Product Managers? - ProductFTW #70 URL: https://www.productftw.com/productftw-70-do-startups-need-product-managers/ Last updated: 2026-10-14T01:25:33.000Z “Do we actually need a Product Manager?” If this conversation is happening, the answer is usually yes. As a consultant, I am rarely brought in when everything is working perfectly. The call usually comes when something feels off, but no one can quite name it. The team has grown, and everyone is working hard, but output is inconsistent. Everything feels slower than it used to. It is tempting to label this a communication problem. By the time the friction is obvious, they have already tried to fix it the logical way: more meetings, new Slack channels, tighter documentation, another project management tool. The instinct is to improve alignment by increasing communication. More communication does not automatically create clarity. As the volume of conversations and artifacts grows, ownership becomes less visible, not more. When you pause to ask who is accountable for the product’s direction, the answer is usually some version of “we all are.” This is nice in theory, but if you are a [RACI](https://it.cornell.edu/it-service-management/raci-and-rasci-definitions?ref=productftw.com) believer, there can and should be only one accountable party. I feel another post brewing. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## **Founder Overload** Early on, the product role is usually owned by founders who are passionate about solving a problem. They are monitoring Reddit channels, doing cold outreach, and directly relaying feedback to engineering. They make prioritization decisions in real-time, and everyone knows what is going on and is aligned on what needs to happen next. Some founders are wired for fundraising or business development and prefer not to own product day to day. If that is true for you, you need to assign product ownership from day one. As the company grows, a founder’s responsibilities shift. Fundraising, hiring, investor updates, partnerships, and long-term positioning need to be their focus. The product and users are still equally important, but are no longer the only thing competing for their time. Decisions start to be made between Zoom calls, slide creation, and answering Slack rather than consuming their entire focus. Feedback is still coming in from everywhere, but there is less time to sit with it, connect the dots, and translate it into clear priorities. Founders believe they are still setting direction, and technically, they are. The difference shows up in how tradeoffs get evaluated. When product is no longer the primary focus, decisions are more likely to be shaped by the most immediate need. A large prospect’s request, a partnership opportunity, or a narrative that supports the next fundraise can and will swap priorities in the moment. There is nothing wrong with this shift. Someone needs to be advocating for these new responsibilities. Without someone consistently focused on maintaining a clear product direction and long-term prioritization, it becomes harder to evaluate feedback in context and prioritize it deliberately, which can gradually turn into thrash and scope creep. ## **Why Engineers Notice First** Engineers usually feel the pain first. They are heads down shipping and responding to whatever the business needs most urgently. When priorities change frequently, work gets paused midstream or deprioritized after meaningful effort has already gone in. From their point of view, a lot of energy is being wasted without a clear sense of progress. ![Meme of a man debating between two buttons capitoned "Strategy" and "Last customer request" with the prompt "Do we need a product manager?"](https://www.productftw.com/content/images/2026/02/product-manager-meme.jpg) Spoiler: they pick the last customer request every single time. Most engineers do not just want to close tickets. They want to build things that matter. They want to see their work ship, stick, and drive impact. When direction shifts too often, it becomes harder to tell whether they are building toward something or just reacting to the loudest customer. That uncertainty is what creates frustration. It is not the workload; it is the lack of visible, sustained value creation. ## **The Two Common Responses** When founders sense this frustration, they typically respond in one of two ways. Some attempt to course-correct by inserting themselves more directly into product discussions. They review tickets, attend more meetings, and make more decisions. That approach can provide short-term clarity, but it also makes the founder the bottleneck for product direction. Others step back and trust the team to self-organize around priorities. In highly mature environments with a well-established strategy and strong product leadership, that can work. In growing startups, it often creates ambiguity. Everyone is already stretched thin and operating with partial context, even though they are fully invested in the company’s success. Neither response holds up over time because neither addresses the underlying issue. ## **When You Need to Hire Product** You need to hire a Product Manager when misalignment starts costing real money. Engineering time is spent revisiting decisions that were already discussed. Meetings increase because alignment does not hold. Teams ship work that is technically complete but does not actually solve the user’s problem. Engineers are busy, but if you ask what meaningful outcome their last few sprints created, the answer is not always clear. Customer feedback accumulates faster than it can be translated into real requirements. You also see it in smaller ways. Roadmaps shift mid-sprint. Priorities change after a single customer call. Work gets half finished because something more urgent suddenly appears. Teams start optimizing for responsiveness instead of impact. None of this looks dramatic from the outside. The team is still shipping, and revenue may even be growing, but internal costs are rising. ## **What You Are Actually Hiring For** This is where many teams get it wrong. A Product Manager at a growing startup is not there to run standups or keep a ticketing system organized. The role is not administrative. You are hiring someone to [own the problem space](https://www.productftw.com/productftw-69-project-product-program-managers-and-owners/). That means they understand how the company makes money, how customers derive value, and how the product actually works. They have enough business context to push back when a request does not align with strategy, and enough technical credibility to earn engineering’s trust. Ownership in this context means synthesizing feedback across sales, support, customers, leadership, and engineering. It means separating real patterns from one off requests. It means defining what success looks like before work begins and revisiting that definition after launch to determine whether the outcome matched the intent. When this is done well, priorities do not stop changing, but the reasoning behind those changes is clear. Tradeoffs are explicit and work builds on itself. Founders can step back from daily prioritization without feeling like direction is slipping. ## **The Real Question** Startups do not need a Product Manager on day zero if the team is small enough that context spreads naturally. In the earliest stage, the founder can and should own product directly. If this question keeps coming up in leadership meetings, it is usually not abstract. It shows up in how the company is operating. Decisions take longer than they used to. Alignment feels heavier. Tradeoffs are harder to reason through. That does not mean anything is broken. It usually means the company has outgrown informal product ownership. I have yet to see a team regret hiring product once they were truly ready for it. At some point, someone needs to clearly own how vision turns into prioritized work and shipped outcomes. When that ownership is spread across too many people, the company is already paying for it. It just has not put a name next to it yet. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Product, Project, Program Managers and Owners - ProductFTW #69 URL: https://www.productftw.com/productftw-69-project-product-program-managers-and-owners/ Last updated: 2026-05-22T02:07:23.000Z Someone told me recently that they were a “product owner,” and it sent me down the usual spiral of titles, responsibilities, and what people actually mean when they describe what they do. Product roles have multiplied. As [Scrum](https://www.scrum.org/learning-series/what-is-scrum/?ref=productftw.com) entered the workforce, [agile](https://www.atlassian.com/agile?ref=productftw.com) became a job title, and now we have product managers, product owners, project managers, program managers, Scrum Masters, delivery leads, and more. The titles keep expanding, but the core responsibilities haven’t changed that much. We’ve just sliced them into more specialized pieces. At the highest level, I believe there should be a clear division: - Technology owns the “how” - Product owns the “what” and “why” - Everyone is responsible for the “when” That’s the cleanest version of it. Everything else is nuance. Let’s walk through the common roles and what they are actually responsible for. ![Table comparing Product Manager, Product Owner, Project Manager, and Program Manager, showing each role’s primary responsibility and primary success metric.](https://www.productftw.com/content/images/2026/02/image.png) When your org chart needs a decoder ring. ## Project Manager A project manager is responsible for when something gets delivered. They partner closely with engineering to understand the plan, track progress, surface risks, and keep timelines realistic. They are not deciding how the system is built, and they are not deciding what should be built. They are ensuring there is a plan and that the plan is being executed. Their success metric is simple: was it delivered on time? If not, did we know early enough to adjust? It’s a critical role in complex environments. In early-stage startups, this role is often absorbed by product, engineering leads, or operations because there’s usually one main initiative and one engineering team. Once you have multiple teams or overlapping timelines, dedicated timeline management becomes much more valuable. Managing time well is not trivial. It’s a skill. It’s just a different skill from defining product strategy. ## Program Manager Program managers operate at a broader level. Instead of managing one project, they coordinate multiple related initiatives that roll up into a larger company objective. For example, launching a new onboarding flow is a project. Launching a new card product is a program. It may include underwriting changes, compliance review, marketing updates, servicing workflows, reporting, and operational readiness. Each of those is a distinct project, but they must be delivered together for the product launch to succeed The program manager ensures those moving parts align. Ideally, without 47 status meetings. They manage cross-team dependencies, escalate risks, and maintain visibility across workstreams. Their success metric is not just whether something shipped on time. It’s whether the overall objective came together in a coherent way. In larger organizations, this role becomes essential because complexity compounds quickly. In startups, it’s often handled by product, operations, or leadership simply because there aren’t enough parallel initiatives to require a dedicated owner. That’s where things start to get fuzzy, especially once Agile terminology enters the room. ## Product Owner Product owners are most commonly associated with a Scrum or Agile construct. In organizations that separate the roles, they focus primarily on execution. A product owner typically owns the backlog. They write and refine user stories, define acceptance criteria, prioritize work within a sprint, and clarify requirements for engineering. They are responsible for ensuring that what gets built matches what was asked for. They usually review work in sprint demos, accept or reject stories, and ensure the team meets the definition of done. At that level, they are responsible for making sure the feature works according to the requirements. What they are not typically responsible for is company-level strategy, long-term product direction, budgeting, or defining broader business outcomes. That responsibility usually sits with a product manager. You rarely see a standalone product owner in early-stage startups because the separation does not make much sense. When there is one product person, they are usually responsible for both strategy and execution. Splitting the roles too early just adds overhead. ## Product Manager Product managers tend to wear the most hats. In addition to writing requirements and managing backlogs, they work with customers, conduct interviews, analyze data, define success metrics, shape the roadmap, and think about long-term direction. They are responsible for defining the “what” and the “why”. They sit at the intersection of users, business goals, and engineering constraints. They are accountable for outcomes, not just output. Where the distinction becomes clear is around responsibility. A product owner is typically responsible for ensuring a feature meets requirements and is accepted into production. A Product Manager is responsible for ensuring the team built the right thing in the first place and that it actually worked after it shipped. That includes pre-production validation, post-production monitoring, and communication. Reviewing features in staging. Making sure edge cases were considered. Writing release notes. Watching metrics after launch. Answering the uncomfortable question of whether the thing delivered the result you said it would. A product manager’s job does not end at “it shipped.” It ends at “did this move the metric we said it would?” In startups, product managers often absorb project and program responsibilities because someone has to. In larger organizations, those boundaries become more defined. The core responsibility remains the same: own the problem, own the outcome. ## Can These Roles Overlap? Yes. Can a product manager act as a project manager? Absolutely. It happens constantly in startups. Can a project manager act as a product manager? That’s harder. Timeline management and stakeholder coordination are different skill sets from defining strategy, understanding customer problems, and shaping product direction. Both are valuable. They’re just not interchangeable. Do you need both or all of these roles? No. Make your Product Manager do it. ## Where It Gets Messy The confusion starts when titles become shields. - “I’m just the product owner.” - “That’s the project manager’s job.” - “That’s not in my scope.” In a startup, **everything is your scope.** As companies grow, specialization makes sense. Clear role definitions make sense. Measurement clarity makes sense. But the core concepts stay the same: - Someone defines what and why. - Someone determines how. - Someone ensures it happens when it should. - Someone ensures the pieces align. Those are functions. The titles just describe how those functions are distributed. ## The Real Point The more titles you introduce, the more important clarity becomes. Each role should know what they are accountable for and how they are measured. Otherwise, you create overlap without ownership, which is where things actually fall apart. At the end of the day, product is about deciding what to build and why. Technology is about deciding how to build it. Delivery roles ensure it happens when it should. Coordination roles ensure it all makes sense together. Everything else is how the organization chooses to divide the work. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Credit Card Repayment Timing Is a Product Decision - ProductFTW #68 URL: https://www.productftw.com/productftw-68-credit-card-repayment-timing-is-a-product-decision/ Last updated: 2026-06-04T19:27:28.000Z Have you ever wondered what the last possible moment is to make your credit card payment without it being late? If you haven’t, that’s great. If you’ve ever been tight on cash, waiting on a paycheck, or just mildly curious, you’ve probably assumed that the answer should be easy to find in your credit card app. ![Images of repayment screens from Barclays, Chase, American Express, Coinbase, and Apple.](https://www.productftw.com/content/images/2026/02/repayment-time.png) It took me over an hour to find all of these in the app. As it turns out, sometimes it isn’t. The exact cutoff time can be buried three or four clicks deep, hidden behind generic “due today” language that sounds clear until it’s 10:47 pm and you’re doing the math in your head. Not every user can pay early. When you’re tightly managing your money, timing matters. The less clear the product is about that timing, the more anxiety it creates right at the moment someone is trying to do the responsible thing. [In Product FTW #67](https://www.productftw.com/productftw-67-why-credit-card-payment-options-confuse-users/), I wrote about repayment options and why the boring-looking text on a payment screen matters more than it seems. This week is about timing: when a payment is made, when it’s applied to an account, and when it’s considered “on time.” These are often treated as implementation details, but they shape how users experience repayment each month, especially when they’re trying to avoid late fees. ## When a Payment Counts Most users assume a payment is applied the moment they hit submit. That assumption is reasonable. It just doesn’t align with how many credit products work, which is why repayment generates so many support tickets. At a high level, issuers tend to make one of two choices. Some apply a payment immediately when the user submits it. The balance drops, available credit increases, and the product reflects the action right away. American Express is a common example of this approach. Seeing your balance move immediately is oddly satisfying. It doesn’t change how much money you have, but it reassures users that something happened and the payment actually went through. Other issuers wait until the payment posts and clears before updating the balance and available credit. This approach is more common, especially among smaller issuers and newer programs. Neither option is “right.” They optimize for different tradeoffs. Applying payments immediately improves perceived responsiveness, but it introduces risk. The payment can still fail due to insufficient funds, a canceled transfer, or bank issues. In the meantime, the user may already have spent the additional available credit. When that happens, the product has created a problem it now needs to unwind. Waiting until the payment posts reduces that risk, but it creates a different kind of confusion. From the user’s perspective, they paid their bill, nothing changed, and now they’re wondering whether they misunderstood something or clicked the wrong button. The system is behaving exactly as designed, but the experience doesn’t make that obvious. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## “Why Is My Payment Still Pending?” Timing becomes visible when payments take longer than users expect. How long a payment takes to apply depends on when it is made, the payment method, the user’s bank, and whether weekends or holidays are involved. In practice, three to five business days is typical, even though it rarely aligns with user expectations. Even the time of day matters. Payments made late in the evening are often treated differently than those made earlier, because bank cutoff times determine whether a payment is considered same-day or pushed to the next business day. Most users have no idea those cutoff times exist, and there’s no reason they should. From the system’s point of view, a pending state is normal. From the user’s perspective, their money has disappeared into the void. If someone makes a payment on Thursday night and a long weekend follows, that payment may still be pending on Tuesday. Nothing is broken, but unless the product sets expectations clearly, the experience feels unreliable. Most repayment experiences don’t explain what “pending” actually means. Users don’t think in business days or clearing windows. They think in calendar days, and when money is involved, several days without visible movement are enough to create doubt. If a product waits until payments post before updating balances, that choice needs to be explicit. Showing the time the payment was made, highlighting cutoff times, and setting expectations for multi-day posting help users understand what’s happening rather than assuming they made a mistake. ## When is a Payment Considered Late? Regardless of how payments are applied, users need clarity around one thing in particular: when the late window actually begins. Most credit card products allow payments up to a specific cutoff time on the due date, typically around midnight Eastern Time, even on weekends. Whether Eastern time is used because of banking infrastructure or simple convention matters less than whether the product communicates it clearly. This is where vague language creates unnecessary stress. “Pay by today” sounds fine until it’s late at night and someone is trying to decide whether they still have time. “Pay by 11:59 PM ET” answers that question immediately. Some products handle this better than others. Apple Card is a good example of using limited screen space to reduce ambiguity by displaying the exact cutoff time rather than relying on date-based phrasing. ## The Complexities of Autopay Autopay exists for many reasons. It reduces missed payments, users like not having to think about due dates every month, and it generally improves on-time payment rates. Implementing it is where things become more complicated because autopay still operates under the same constraints as manual payments: weekends, holidays, bank cutoff times, and posting delays still apply. When an autopay payment is delayed or fails, the experience is often worse than a missed manual payment. The user followed the product’s recommendation, and the outcome still didn’t match their expectations. Autopay also creates edge cases with one-time payments. If a user submits a manual payment that is still pending, product teams need to decide whether to run autopay, adjust it, cancel it, or wait. If both payments go through, the user can easily overpay their balance. Allowing overpayment creates downstream operational work. Once a user pays more than they owe, the issuer now owes the user money. Returning those funds, ensuring delivery, and tracking unresolved balances introduces additional complexity, including unclaimed funds and escheatment obligations if the money is not successfully returned. At that point, you’re no longer just building a repayment flow. You’ve created a very small, very annoying refund operation. The safest approach is usually to prevent overcollection in the first place. Autopay needs guardrails that account for pending payments so the system never takes more than the user owes. ## Conservative Timing Is Usually the Right Choice Some large issuers can afford to be aggressive with repayment timing because they have the balance sheet, controls, and operational maturity to apply payments early and deal with failures later. Most startups do not. Waiting for payments to post reduces risk and avoids situations where users spend money that has not actually cleared. That choice doesn’t have to result in a bad experience, as long as the product explains what is happening and sets expectations clearly. Different products will make different choices. Secured cards, charge cards, and revolving credit all behave differently, and that’s fine. What matters is that these timing decisions are intentional and visible to users. ## Where This Actually Shows Up Repayment timing rarely looks like a feature. It shows up as a timestamp, a cutoff notice, or a small line of text that most users barely notice. Those details are where expectations are either set correctly or quietly broken. When users understand when a payment counts, pending states feel normal. When they don’t, delays feel suspicious. If you care about limiting confusion at the moment of repayment, timing deserves far more attention than it usually gets. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Why Credit Card Payment Options Confuse Users - ProductFTW #67 URL: https://www.productftw.com/productftw-67-why-credit-card-payment-options-confuse-users/ Last updated: 2026-06-04T19:27:26.000Z Paying a credit card bill should be simple. Log in, pick a number, submit payment, move on with your life. In reality, repayment is one of the most complex user experiences in consumer finance. One specific aspect of that complexity is the repayment options themselves and how they are defined, presented, and explained to users. ![Images of payment option defintions from Apple, Capital One, Chase, American Express, Barclays, and Coinbase.](https://www.productftw.com/content/images/2026/02/payment-options.png) The most interesting part is that everyone had the same amount of screen space to work with. These sound straightforward: minimum payment, statement balance, current balance, and other amount. They are not. Each option changes how interest works, when it accrues, and how much the user ultimately pays, which is rarely obvious when you’re staring at the payment screen. ‼️ Quick disclaimer before we go further: I am not a compliance person. If you are building a credit card repayment experience, you should work closely with compliance, review CFPB guidance, and understand issuer-specific rules. This article is about product decisions and user experience, not legal advice. When I work on card products, I spend a disproportionate amount of time on repayment. Not because it’s exciting, but because it’s dangerous and I am paranoid. Repayment sits at the intersection of real money, regulation, math, and user behavior. You don’t get to be hand-wavy here. Every choice has consequences, whether the user understands them or not. That said, “compliance made us do it” is not an excuse for a confusing experience. Product managers still own the UX. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Grace Periods: The Part (Almost) No One Understands Before we get into the repayment options themselves, I need to touch on grace periods and how they actually work. I can’t avoid this part, because most of the confusion around repayment options only makes sense once you understand what a grace period is and when it disappears. At Totavi, we spend a surprising amount of time explaining grace periods to people. Not because they’re obscure, but because they’re unintuitive. Even users who have had credit cards for years often misunderstand when interest accrues and which actions reset (or don’t reset) the clock. Grace periods sit underneath every repayment option on the screen. Whether a user pays the minimum, the statement balance, or something in between, the real question they’re implicitly asking is the same: **will this cause interest to accrue?** Here’s the rule most revolving credit cards follow: - If you pay your statement balance in full by the due date, you keep your grace period, and you don’t pay interest on purchases. - If you don’t pay the full statement balance by the due date, you lose the grace period. - Once the grace period is gone, interest starts accruing immediately on any remaining balance. This is the part that surprises people: new purchases can also start accruing interest daily until the grace period is restored. - Paying the balance down to zero does not automatically fix this. To restore the grace period, you usually need to let a full statement cycle close with a zero balance, then pay the following statement in full. Until that happens, interest continues. Most issuers work this way. Payments are allocated in accordance with issuer rules. Interest accrues daily. The grace period does not magically reset just because a payment is posted. None of this is obvious from a repayment button. Which is unfortunate, because that button is doing a lot more work than it seems. ## Why Repayment Options Are Confusing Now layer that reality on top of the repayment options we give users. **Statement Balance** The statement balance is the amount owed at the end of the previous billing cycle. Once the statement closes, that number stays fixed until it’s paid down, no matter how much the user spends afterward. Conceptually, it’s calculated as: - Prior balance - Plus new purchases, fees, and interest - Minus payments and credits - As of the statement close date Paying the statement balance in full and on time is what preserves the grace period. From a product perspective, this is the most important option on the screen. If users misunderstand this one, everything else cascades. **Current Balance** The current balance is a real-time total of what the user owes today. It includes posted transactions, fees, interest, and payments. It does not include pending charges. This number changes constantly. Every posted transaction updates it. Users often assume paying the current balance is the “safe” option. Depending on timing, that is not always true. Paying the current balance does not necessarily preserve or restore the grace period, and most products do a poor job explaining that nuance. **Minimum Payment** The minimum payment is the smallest amount required to keep the account in good standing. It has a defined calculation and regulatory constraints. Paying the minimum avoids late fees and delinquency. It does not avoid interest or preserve the grace period. And over time, it can be very expensive. From a UX perspective, this option needs especially clear language. Paying the minimum is not a neutral choice, and treating it like one is misleading. **Other Amount** “Other amount” looks flexible and user-friendly. It’s also where things get risky. If a user enters less than the minimum, there are consequences: late fees. potential delinquency, and credit reporting impacts. This option needs guardrails and explicit warnings, not just an empty input field. ## Where Product Teams Usually Go Wrong Most teams default to what traditional issuers have done for years. They drop a lot of explanatory text on the screen. Paragraphs describing what a statement balance is, how a current balance is calculated, or why minimum payments exist. Users don’t read those paragraphs at the moment they’re making a payment. They skim, or they ignore them entirely. Then they pick a number and hope they didn’t just mess something up. Hope is not a great repayment strategy. What users actually want to know is much simpler: - Am I going to pay interest? - Am I going to be penalized? - Is this going to hurt my credit? - Did I just make a mistake? Most repayment experiences don’t answer those questions directly. They explain the mechanics and assume the user will infer the outcome. That’s a big assumption, especially when real money is involved. The better experiences flip this. Instead of leading with definitions, they lead with consequences. They make it obvious what happens if you don’t pay the statement balance in full. ## Examples That Do This Well Two repayment experiences I consistently point to are Apple Card and the Coinbase credit card. Both prioritize clarity over abstraction. They make it obvious what happens if you don’t pay the statement balance in full. ![Screenshots of Coinbase's repayment experience on mobile.](https://www.productftw.com/content/images/2026/02/data-src-image-414412b0-bd9b-4e5a-84e7-9d05177b2cdc.png) Coinbase is the only experience where I couldn’t find additional explanatory text. Probably intentional. Apple Card, in particular, shows the dollar cost of carrying a balance, not just an APR, and goes a step further by clearly showing the payment cutoff time. It also saves users from doing math they were never going to do anyway. ![Screenshots of Apple's repayment experience on mobile.](https://www.productftw.com/content/images/2026/02/data-src-image-2984fb78-07b1-4327-9913-59d09c499ec5.png) I never thought paying my card would be fun. ## What I Optimize For When I design repayment flows, I’m not trying to be clever. I’m trying to eliminate ambiguity. I want users to know, at the exact moment they select a payment amount, whether that choice will cost them interest. I want outcomes to be obvious without forcing people to understand billing math or issuer rules. Lastly, I always assume that grace periods are misunderstood, because they almost always are. Repayment is not a settings screen you visit once. It’s a monthly decision that shapes whether users trust your product or feel like it tricked them. When you get it right, no one thinks about it. When you get it wrong, everything else feels suspect. That’s why repayment options are real product work. Turns out the boring-looking text on the payment screen matters more than it seems. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Authentication in Fintech - ProductFTW #66 URL: https://www.productftw.com/productftw-66-authentication-in-fintech/ Last updated: 2026-06-04T19:27:25.000Z This year at ProductFTW, we will spend more time talking about fintech and real product work. I think it is exciting to focus on the day-to-day decisions PMs have to make when money, regulation, and risk are involved. Lucky for our readers, this is something the ProductFTW team works on every single day at Totavi. When I start a new card product, the first meaningful requirements I write are almost always about account creation and authentication. ![Image of login screens for American Express, Capital One, Chase, and Barclays.](https://www.productftw.com/content/images/2026/01/image-3.png) Yes–all financial products are blue. Blue means trust. I'm blue, da-ba-dee, da-ba-di. Most people think authentication is a solved problem. That assumption usually holds until real money is involved. Log in, log out, reset your password. There are vendors, SDKs, and best practices for all of it. As Matthew stated in [ProductFTW #46](https://www.productftw.com/productftw-46-building-user-authentication/): > Auth lives in this awkward space: critical to your product but rarely a core differentiator.” Fintech adds another layer of constraints on top of that. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Why Fintech Auth Looks Different If you spend most of your time building non-financial consumer products, banking apps often feel behind. Many of them do not support Google login or other common single-sign-on (SSO) options. That choice is intentional. In fintech, authentication is closely tied to identity, fraud, and regulatory responsibilities. When a bank authenticates a user, it grants access to money, personal data, and regulated actions. Adding a third-party identity provider introduces a dependency that the bank does not control. If that provider changes behavior, experiences an outage, or locks a user out, the bank still owns the outcome. Support tickets rise, fraud risk increases, and regulators still point the finger at the bank. Recovery flows matter just as much: When something goes wrong, banks need clear answers about who accessed an account, how they authenticated, and what signals were present at the time. That level of visibility is harder to maintain when authentication relies on external identity systems. There is also a platform constraint that many teams underestimate. Supporting Google SSO on mobile means supporting Sign in with Apple on iOS. That adds additional flows, testing paths, and edge cases. Each provider has different rules for account linking and recovery, which quickly increases complexity. This is why SSO debates in fintech usually end in “we’ll revisit this later” and quietly sit on the backlog. ## Mistakes I See Someone drops a login screen into Figma, writes a generic user story about needing to access an account, and moves on. It feels harmless because authentication appears as a component rather than a system. In fintech, that assumption breaks things later. Authentication decisions are data model decisions. The moment you decide when an account exists, you are deciding which objects exist in your system, which relationships are valid, and what data you store about someone before they ever become a customer. This is where the applicant-to-cardholder lifecycle starts to matter. - Are you creating a user record before submitting an application? - Are you creating an account before underwriting? - Are identity verification attempts attached to a person who may never be approved? - Does a customer ID get generated early and flow into downstream systems? - Are you cleanly converting an applicant into a cardholder, or layering on status flags to make it work? Most PMs do not realize they are defining the ERD when they choose an account-creation strategy. Engineering will still build something, but it will be shaped by whatever decision was implicitly made in the application flow. Months later, you end up with awkward entities that only exist to paper over that choice. In practice, the lifecycle usually looks something like this: 1. A visitor shows up and starts an application. 2. That visitor becomes an applicant once they submit their personal information. 3. An applicant becomes an approved account holder after underwriting. 4. An approved account holder becomes a cardholder once a card is issued and activated. Those are different states with different permissions, data requirements, and compliance implications. They should not all collapse into a single account object just because it makes login easier. ## When Does the Account Exist? Once you start thinking about authentication as part of the lifecycle and data model, the next decision becomes unavoidable: When does the account actually exist? In card products, this usually comes down to two options. Creating the account before the application or after approval. Creating the account early establishes a persistent identity. Users can save progress and return to an in-flight application. Activity can be tied to a known user instead of a temporary session. This approach works well when the card is embedded into an existing product that already has a login. The user already has an account, and the card is additive. Early account creation fits naturally into that experience. The downside is friction. Every additional step before application submission increases drop-off. Asking for credentials before a user has committed to applying introduces risk to conversion. Creating the account after approval removes that friction. The user focuses on applying. Credentials come later, once there is a reason to log in. The tradeoff shows up downstream. Saved applications are harder. Returning users require more logic. Temporary identifiers eventually need to be reconciled into real accounts. There is no universally correct answer. Embedded finance products often create accounts earlier. Standalone card products tend to delay account creation. My preference is to create the account after approval. It keeps the application flow lighter and avoids storing large volumes of personal data for users who never make it through underwriting. Once an account exists, your data model, compliance obligations, and retention requirements change. Reversing that decision later is expensive. ## Email vs Username Once you decide when the account exists, the next decision is how users identify themselves. Have you ever wondered why most major credit card issuers use usernames rather than emails? After reviewing some of my card logins, Chase, Amex, Capital One, and Barclays all use usernames and passwords. This is because emails change, people lose access, work emails get shut off, and shared inboxes disappear. When email is the primary identifier, account recovery becomes a frequent problem, and account access gets tightly coupled to communication. Usernames are more stable. They separate authentication from communication. That separation matters during fraud investigations, recovery flows, and legal processes. It also reduces the number of lockouts caused by email changes. Early-stage products often default to email-based login because it feels easier. At a small scale, that works. At a larger scale, it creates cleanup work. That is why legacy issuers stick with usernames, even when it frustrates new users to remember application-specific ones. ## Password Requirements Password rules quickly surface as a point of tension between product, security, and fraud teams. Password guidance has changed a lot over time, largely driven by NIST. Older standards pushed complexity rules, frequent rotation, and forced resets. That led to predictable behavior. Users reused passwords, wrote them down, or made small variations that were easy to guess. Newer NIST guidance shifted toward longer passwords, fewer arbitrary rules, and rotation only when there is evidence of compromise. The goal was to reduce user friction while improving real-world security. In fintech, that guidance is a starting point, not a ceiling. Many teams still choose stricter requirements based on fraud patterns, threat models, and regulatory expectations. Lately, guidance often points to 8 to 15 characters and discourages forced complexity. That makes sense until you have dealt with credential stuffing and account takeover attempts. Stricter requirements reduce certain risks and increase friction. Looser requirements improve conversion and increase downstream costs. This is a business decision with operational consequences. PMs run into trouble when password requirements are treated as a UX choice. In fintech, these decisions affect fraud exposure, support volume, and regulatory posture. Fortunately, many phones and browsers now offer password suggestions. As my family knows (not that I would ever share streaming passwords), I am fully on board with device-generated passwords. I don’t think it is unrealistic to require 15-character passwords with numbers and special characters. ## Remember Me, Face ID, PINs After initial login, speed becomes the focus. Users expect faster access over time. Features like remember me, Face ID, PINs, biometrics, and passkeys all make that possible, and each one shifts how risk shows up. Persistent sessions increase exposure when a device is lost. Biometrics and passkeys shift trust to the device and operating system. PINs can become weak points if implemented poorly or reused elsewhere. Passkeys are interesting because they remove passwords entirely and reduce phishing risk, which is a real win. They also introduce new considerations around device portability, account recovery, and cross-platform support. If a user loses a device or switches ecosystems, recovery flows matter a lot more than they do with passwords. This is why financial apps tend to be conservative on first login and on new devices. Step-up authentication is common. Trust is built over time. When I build applications, I usually start with more friction. SMS-based MFA, device verification, and conservative session policies help establish confidence early. Faster login options can be layered in once the user and device are familiar. ## Layered and Contextual Checks In fintech, authentication rarely relies on a single signal. Device, IP, and location data are commonly used to add context and reduce fraud without adding visible friction for every user. These signals are evaluated together. A familiar device on a consistent network behaves differently from a new device in a new location. When multiple signals change at once, teams can step up authentication instead of treating every login the same. This approach reduces reliance on any single factor and lets products respond to risk dynamically. Most users move through the flow without interruption, while higher-risk scenarios trigger additional checks. ## Why This Matters for PMs Authentication is not a feature users praise. It is a feature they notice when it breaks. In fintech, failures are expensive and difficult to unwind. PMs often want to move past authentication quickly so they can focus on the rest of the product. That instinct is understandable, but carries risk. Authentication decisions shape conversion rates, fraud exposure, support costs, and the compliance posture for years. Auth is hard in fintech because every decision trades convenience for control or speed for safety. Get it right and users barely think about it. Get it wrong, and everything else suffers. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Sticking to your Vision - ProductFTW #65 URL: https://www.productftw.com/productftw-65-sticking-to-your-vision/ Last updated: 2026-05-10T23:40:56.000Z ### **Vision Is a Decision, Not a Mood** Every startup claims to have a vision. Very few actually behave in ways that demonstrate commitment to that vision. Most teams talk about vision the way people talk about New Year’s resolutions. It sounds inspiring in January, feels negotiable by March, and quietly disappears the first time things get uncomfortable. That is not a vision. That is optimism without commitment. A real vision is not an aspiration. It is a decision. Once you've made it, your job as a founder or product leader is to stick with it long enough for it to matter. That’s not to say you must stick to it forever and mindlessly, but long enough that the organization can actually align around something real. If you constantly revisit fundamental decisions, you do not have a vision. You have a brainstorming session that never ended. ![Meme of Morpheus from The Matrix saying "What if I told you that organizations can write whatever they want in their mission statement"](https://www.productftw.com/content/images/2026/01/image-1.png) ### **Creating a Vision Means Ruling Things Out** A company vision is not to “build great products” or “delight customers.” Those are baseline expectations, not strategy. A vision only becomes useful when it is specific enough to create constraints. “I want to build the world’s leading business expense credit card that makes small business owners' lives better” is a vision not because it is lofty, but because it forces hard tradeoffs. It implies regulatory complexity, issuing partners, fraud, underwriting, compliance, disputes, customer support, capital requirements, and time. It is difficult by definition. That difficulty is not a flaw. It is the entire point. Founders often think a vision should feel motivating and energizing. It should, but it should also feel uncomfortable. A good vision immediately creates tension with reality and exposes what you are signing up for. If it does not, you probably have not gone deep enough. ### **Sharing the Vision Is Ongoing Work** Founders love announcing vision. They make decks, write Notion pages, and run all-hands meetings. Then, months later, they are frustrated that the team “isn’t aligned.” ***Alignment does not come from exposure. It comes from repetition.*** Your team does not wake up every morning thinking about the company’s long-term direction. They are thinking about tickets, customers, deadlines, and whatever is on fire today. If you are not explicitly tying everyday decisions back to the vision, alignment will decay. Sharing the vision means reinforcing it constantly, in product reviews, roadmap debates, hiring decisions, and customer conversations. Over time, people should be able to anticipate your answer to a question before you give it. In a larger organization, I love to start every all-hands with a repeat of the company vision and mission slides. It drills it into people. You should be able to ask anyone in the company: “What’s our vision?” and receive an answer that is 95% accurate. It can seem overbearing to repeat it, but in my experience, it is necessary (especially after a shift). That is not redundancy. That is leadership. ### **Vision Exists to Make Decisions Easier** The main reason vision matters is that it simplifies decision-making: if everyone is looking at the problem with the same goals, they are more likely to agree on immediate next steps. When new opportunities appear, the question is not whether something is interesting or whether it could work. The question is whether it moves the company closer to the destination you already committed to. This is where many teams quietly go off the rails. The pattern usually looks like this: 1. You want to build a business credit card. 2. You discover that building a credit card is hard. 3. You notice that business debit cards are easier to use. 4. You convince yourself that building a debit card is a reasonable interim step. It usually is not. Debit cards are not a stepping stone to credit cards (at least, not in this example!). They are a different product with different economics, different customer behavior, and different long-term outcomes. Choosing debit because it is easier is not pragmatism. It is avoidance. You did not learn something new. You flinched. That is fine if you are honest about it, but do not pretend you are still executing on the same vision. You are not. ### **The Real Work Is Sticking to Decisions** Making decisions is not the hard part of leadership. Sticking to them once the friction shows up is. Every difficult week, you will try to renegotiate your vision. Sales will want exceptions. Engineering will want to narrow the scope. Partners will want compromises. Investors will want optionality. Your job is to absorb that pressure and still say, “Yes, this is hard. We already knew that. We are still doing it.” Most companies do not abandon their vision in a dramatic pivot. They erode it slowly through a series of small exceptions that feel reasonable in isolation. One special customer. One temporary workaround. One shortcut that becomes permanent. Later never comes. (For more on this, read [ProductFTW #23](https://www.productftw.com/productftw-23-opinionated-product/)) ### **Adaptation Is Not the Same as Panic** There is an essential difference between abandoning a vision and adapting how you pursue it. Wallaby is a helpful example: The original idea was a cloud wallet that automatically optimized which credit card you used for each purchase. The card networks would not allow it, which was a hard external constraint. The core vision was not “be a wallet.” The core vision was to help people optimize their credit card usage. So the product evolved into auto-alerting and context-aware recommendations using transaction data, location, and behavior. The implementation changed, but the underlying value did not. That is not a pivot away from vision. That is commitment to it. Walking away from credit entirely because issuing is difficult is something else. Those two things should not be confused. ### **Your Team Has to Stick Too** This is the uncomfortable part that many founders avoid. Before a decision is made, discussion, dissent, and debate are healthy and necessary. After a decision is made, alignment matters more than consensus. If every strategic decision gets reopened indefinitely, you are teaching your team that decisions are provisional and authority is imaginary. At some point, it is reasonable to say, “We talked about this. We decided. This is the direction. No, we are not changing our mind.” I’ve had team members who couldn’t get on board with this. Unfortunately, that’s a point of hard decisions; those folks need to align or leave. That is not being controlling. It is providing stability. People cannot row in the same direction if the direction keeps changing. ### **Alignment Beats Speed** Early-stage companies love to talk about speed. Move fast, iterate, pivot. Speed without alignment is just thrashing. Small teams win by being focused, and focus requires shared context and durable decisions. If half the team thinks you are building a credit product, another group thinks you are building a payments utility, and a third group thinks you are just experimenting, you are not a startup. You are a group chat. Vision turns individual effort into leverage. Without it, every decision feels heavier than it should, debates feel existential, and progress feels random. ### **Vision Requires Discipline** Sticking to a vision does not mean ignoring reality. It means being explicit about what you are changing and why. If the vision itself is wrong, change it deliberately and say so out loud. Reset expectations and do the work. What kills companies is not changing their mind. It is pretending they have not. Vision deserves respect. Treat it like a decision you already made, not a mood you check in with when things get hard. Because they will get hard. That was the point. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders succeed by offering realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### You Should Be Vibe Coding - ProductFTW #64 URL: https://www.productftw.com/productftw-64-you-should-be-vibe-coding/ Last updated: 2026-05-10T23:40:54.000Z Everybody wants to talk about AI right now. “AI is going to replace jobs, automate your workflows, run your company for you…” blah blah blah. I disagree, but that’s another article. This one’s about vibe coding. And why you, as a product manager, should be doing it. ![Image of a meme with the caption "Its time to vibe my friends".](https://www.productftw.com/content/images/2026/01/image.png) Sorry Gen Z, Millennials have been vibing for over a decade - See "Don't Kill my Vibe" by Kendrick Lamar (Is he canceled now?) ## **What I Mean by Vibe Coding** Let’s set the record straight before we go any further: As a product manager, you are not an engineer. You are (likely) not a trained developer. You should not be shipping production code. And for the love of all that is secure, do not open up vulnerabilities in your stack because you wanted to vibe. Okay, with that out of the way: vibe coding is about using lightweight scripts, AI tools, or quick and dirty automations to poke at your product directly. It is about testing things, validating requirements, and unblocking yourself faster than waiting for engineering or QA to hand you results. Think of it this way: vibe coding is not about building production features. It is about making yourself dangerous enough to run experiments, validate assumptions, and make sure your product actually works the way you think it should. ## **Why Vibe Coding Matters for PMs** Product managers are natural bottlenecks. Not because we want to be, but because so much flows through us. We are writing requirements, answering questions, reviewing designs, prioritizing tickets, and signing off on releases. Often, we cannot move forward until someone else has run a test, filed a bug, or handed us a result. Vibe coding flips that. Instead of waiting, you just do it. You grab a script, spin up a test, or hack together a quick automation. Suddenly, you are not waiting around. You are validating requirements in real-time, and you walk into meetings with data instead of guesses. And let’s be real: as a PM, your job is not just to write a ticket and sit back. Your job is to make sure the thing that ships actually works the way it is supposed to. Vibe coding makes that sign off faster, sharper, and more confident. ## **Example 1: Testing Rewards Logic** I spend a lot of time building consumer credit products. One of the most brutal parts of that job is making sure the rewards logic works correctly. On paper, it is simple: spend in X category, earn Y multiplier. In practice? It is a nightmare. We are talking about +200 different rules. And if you are testing it the “normal” way, you would have to either make transactions in person or go into some half-baked test environment and trigger them one by one. Depending on your processor, that could mean manual API calls or endless UI clicks. It is the definition of painful. Vibe coding turns that all-day slog into a quick run. I can spin-up a script that runs through every single rule, validate that the points are posting correctly, and feel confident in minutes instead of hours. Sometimes I even catch things QA would not, like a rounding rule that did not match our requirements. The result: faster UAT, less pain, and way more confidence when we push to production. ## **Example 2: Onboarding Flow Testing** Rewards are not the only place vibe coding saves me. Onboarding is just as bad, maybe worse. In consumer credit, you do not just onboard one “happy path” user. You need to test dozens of different scenarios. KYC policies. Underwriting decisions. Edge cases. Every variation has to be accounted for. Doing that manually means creating tens of different fake users, each with the right data to trigger the scenario. Over and over and over again. It is exhausting. So instead, I use vibe coding. Pairing ChatGPT with Cypress, I can automate the entire onboarding flow. I generate users with the right data, run them through the UI as if I were a real applicant, and check granular requirements along the way. Did the address error fire correctly for this scenario? Did the right underwriting decision get triggered? Did the KYC check pass or fail the way we expected? Suddenly, instead of clicking through every single edge case, I have automated tests aligned to my requirements. It is fast, thorough, and gives me confidence that the product is actually working the way we promised. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## **Example 3: Scrappy Automations** And then there are the scrappy hacks. At a startup, engineering’s time is gold. They need to stay focused on core product work. Which means if I need to do something like trigger user communications, I cannot just throw it on their backlog and expect it to get done tomorrow. But I also cannot just not do it. So I vibe code. One of the scrappiest automations I have thrown together was connecting our API to Zapier to Campaign Manager. I needed to send automated emails to users based on certain triggers. Instead of begging engineering for a sprint slot, I wired it up myself. API to Zapier to Campaign Manager. Done. Was it elegant? Not really. Was it production ready for the long haul? No. But did it unblock me and keep the product moving? Absolutely. That is the whole point of vibe coding. And it is not just about emails. You can use this approach to automate reporting, test integrations, or even prototype quick flows before design and engineering touch them. It is about being resourceful and keeping momentum instead of waiting around. ## **“That’s Not a PM’s Job”** I can already hear the pushback: “But Ellen, that is not a PM’s job. Testing is for QA. Scripting is for engineers. Automations are for ops.” Sure. But vibe coding is not about taking someone else’s job. It is about moving faster, gathering real feedback sooner (yes, data), and reacting. When you vibe code, you are not stepping on toes, you are catching gaps earlier, answering questions faster, and unblocking your team. You are a better partner to QA because you have validated your own requirements before they even start testing. You are a better partner to engineering because you are not wasting their time with “what if” questions they could have told you in five minutes if you had just hit the API yourself. If anything, vibe coding makes the whole team more efficient. ## **Why This Is Especially Important in Startups** Big companies can get away with the old school model (maybe–I am still skeptical). Engineers engineer. QA tests. PMs write tickets and sit in meetings. But in a startup? That is a death sentence. When you are moving fast, you cannot afford to wait around. Engineering’s focus has to be on core features. QA might not even exist yet. Ops is usually just whoever drew the short straw. That is where vibe coding becomes a startup superpower. It is how PMs keep things moving without blocking the team. It is how you test quickly, automate boring stuff, and build just enough glue to hold things together until the real solution is built. It is not about being perfect. It is about being dangerous enough to get things done. ## **The Bottom Line** Look, AI is cool. It is fun to watch the hype cycle play out. But while everyone else is busy predicting how many jobs AI will eliminate, there is a much more practical skill product managers should be learning right now: vibe coding. It is about making yourself faster, sharper, and more credible with your team. It is about validating requirements, catching issues earlier, and keeping momentum in environments where every week counts. And once you start vibe coding, you will not want to go back. Because suddenly you are not just the PM who writes tickets. You are the PM who knows how the product really works. And that is the kind of PM every team wants. So, yes. Product managers should be vibe coding. Period. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### A Gift from ProductFTW - ProductFTW #63 URL: https://www.productftw.com/productftw-63-new-year-templates/ Last updated: 2026-05-10T23:40:53.000Z ![Image of a gift with a tag that states to: Product Managers from: ProductFTW](https://www.productftw.com/content/images/2026/01/gift-from-pftw-2.png) The best way to start the year. Every January feels familiar. We set resolutions, make plans, buy new notebooks, and convince ourselves that this is the year we will be organized, focused, and ahead of the chaos. The holiday break gives everyone a chance to reset, reflect, and try again. If you work in product, you already know how quickly alignment slips once the year gets moving. Sprint one turns into sprint four, priorities shift, and suddenly, you are reacting instead of leading. This year, we want to help you get off to a great start. Over the holidays, we pulled together a set of practical templates that you can use immediately. These are the tools we reach for in our own work. They remove friction, create alignment early, and save you from reinventing the structure every time someone asks for a brief, a checklist, or a way to evaluate something. Today, we are sharing them with you. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Templates you can use right now ### Product Brief A simple structure to define a new idea and align your team before you start discovery. Use this when you want everyone to agree on the problem, the objective, and how success will be measured. [View the Product Brief template](https://www.productftw.com/templates-product-brief/) ### API Evaluation Checklist A quick way to evaluate partner APIs when you do not have engineering resources available yet or when you want confidence from your own early diligence. Use this before you ask engineers to invest serious time in a vendor. [View the API Evaluation Checklist](https://www.productftw.com/templates-api-evaluation-checklist/) ### Fintech Development Checklist A fintech-flavored checklist that helps you avoid the most common and painful issues that show up in systems dealing with money, time, and asynchronous workflows. Use this before launch or when you are trying to debug something that feels mysterious. [View the Fintech Development Checklist](https://www.productftw.com/templates-fintech-breakage-checklist/) ## Why we built these Everyone loves to talk about outcomes and strategy. The daily reality of product management is different. It is mostly clarity, process, and repeatable tools. You do not always need new frameworks. You need documents and checklists that get everyone aligned quickly and reduce the frequency of having to explain the same thing twice. These templates are designed to do exactly that. They are concise, opinionated, and tailored to the specific kinds of problems that product teams at startups actually face. ## Your turn As you ease back into work and start thinking about this year’s goals, take a moment to bookmark or download the templates that fit your current work. Use one in your next project kickoff or vendor evaluation. Even better, share them with your team and get everyone operating from the same starting point. Here is to a year of clearer thinking, fewer surprises, and product work that feels a little more manageable. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Good, Fast, Cheap - ProductFTW #62 URL: https://www.productftw.com/productftw-62-good-fast-cheap/ Last updated: 2026-05-10T23:40:52.000Z There’s an old adage: Good, Fast, Cheap—pick two. I first saw this on a sign at my barbershop growing up in a small town. These guys were super old school; they were sometimes just gone fishing or golfing, and they changed the price by updating the tiny paper sign with white-out or ink rather than making a new one. Some folks seem to feel like you no longer have to make this trade-off, but I absolutely still think you do. Sure, modern tools, frameworks, and AI make it easier to move faster, but they don’t erase the triangle; they just shift where the corners sit. Beyond just being aware of it, it’s a useful tool for navigating trade-offs and aligning your team. Let’s review Good/Fast/Cheap through the lens of modern software development and product management. # The Triangle, Reframed for Product - Good = Quality: smooth UX, thoughtful architecture, low tech debt, solves a real problem - Fast = Time: how quickly you ship, learn, and iterate - Cheap = Resources: budget, team bandwidth, and opportunity cost While you may not have to choose only two, you certainly cannot excel at all three. By being aware of the tradeoff, you can force clarity into your preferences and approach. ![A white triangle on a dark blue background. At each of the triangle points is a word: good, fast, and cheap. In the middle of the triangle is the phrase "pick two." The Totavi logo is in the top right.](https://www.productftw.com/content/images/2025/10/Triangle-3.png) # Good/Fast/Cheap in The Real World As a fun experience, let’s look at what each of the combinations might get you in the startup world. ## Good + Fast (Not Cheap) You hire a strong team, buy the right tools, and move fast. Results: - Users are happy - You ship on time - Your burn rate goes up This is the playbook for venture-backed startups going for speed over efficiency. (Although, if things don’t go well, these companies wish their burn rate had been lower!) ## Fast + Cheap (Not Good) You throw together an MVP using no-code tools and junior talent. Maybe you vibe-code with AI now. Results: - You test the idea quickly - You don’t spend much - The result is fragile and doesn’t scale This approach is useful for internal tools, prototypes, or early-stage experiments. It aligns with the MVP-style approach or the adage that “if you’re not embarrassed by your first version, you worked on it too long.” I might also refer to this as the version YC promotes. ## Good + Cheap (Not Fast) You invest in open-source tools, optimize for code quality, and avoid shortcuts. - It’s robust and maintainable - It doesn’t break the bank - You’ll be explaining delays for a while I’m never into this one; it feels unlikely to actually work. I have no good examples. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # Why Are Trade-Offs Important? Because trade-offs are the core of product leadership. If you’re not consciously choosing which corner you’re sacrificing, you’re probably doing it *accidentally*. That’s when timelines slip, expectations misalign, and teams burn out. This triangle gives you a shorthand for talking about those trade-offs out loud: - “Are we OK with rough edges if we launch next week?” - “Do we need to spend more to avoid cutting corners?” - “Should we delay to get this right?” It’s not a constraint; it’s a conversation starter. # How to Use Good/Fast/Cheap - In planning: “Which two are we prioritizing this sprint?” - With execs: “We can ship faster if we spend more: Do we want to?” - During reviews: “We got Good + Cheap here, but we knew Fast would take a hit.” Use it to set expectations. Use it to justify decisions. Use it to avoid surprises. Because your users don’t care how you built it. They care that it works. Just make sure your team knows what it *costs* to get there. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### The MVP - ProductFTW #61 URL: https://www.productftw.com/productftw-61-the-mvp/ Last updated: 2026-05-22T02:26:20.000Z One of the great blog posts on product management is Henrik Kniberg’s 2016 post on [“Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable”](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp?ref=productftw.com). You should go read Henrik’s blog post (and then come back and read this one, too). His post includes an important drawing trying to describe how to think about MVPs: ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXf1yQNYCw2WYdod760H9Jks1xqC3dc1Kt4zChL8ApeKONSYVDA0hGMCBv6qRcyBKdPrjtj8Bj0CyQeZk-BlDs2c482cwZIb7Ku6-NvPOWr2U1WQV5KWO2OhMNkH8X1bq2_lsqZkmg?key=Kc4mBPxE5eWt_KXYaRYR5Qr4) [From Henrik Kniberg's **Making Sense of MVP*](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp?ref=productftw.com) I’ve spoken about this so much with my team, we all know it as the “skateboard graphic.” The way I usually summarize the graphic is that you need to think about what problem the user is trying to solve (see [*ProductFTW #12: Determining the Problem to Solve*](https://www.productftw.com/productftw-12-determining-the-problem-to-be-solved/)) and find a usable partial solution, rather than just building parts of what you think is the ultimate solution. In this example, if the problem is "I need to get somewhere fast, and carry things with me," then a wheel doesn’t do anything. However, a skateboard, while not a car, does get you where you are going faster than walking and with a greater ability to carry something. # Over-used Terms The phrase “minimum viable product” (MVP) is overused because it’s often hard to get folks to agree on both what “minimum” means in any context and what makes something “viable.” Many people use MVP as the shorthand for the first thing they are willing to ship and make available to the public. Some folks use it to refer to intentional beta products or test products. Folks love to quote LinkedIn co-founder Reid Hoffman’s saying, “If you are not embarrassed by the first version of your product, you've launched too late” as a way to justify shipping partial products. \[Ed. note: We couldn't find the original publication of this quote, but here's [an essay Hoffman wrote](https://www.linkedin.com/pulse/arent-any-typos-essay-we-launched-too-late-reid-hoffman/?ref=productftw.com) saying he coined it in 2007.\] We spend a lot of time with our clients discussing how to align on internal tests, external tests, and public launches as a way to talk about what each phase is. Since the term “MVP” can mean different things inside a team, everything must be crystal clear. # It’s All About Shipping In startups and in new projects in big companies, many projects are trials. It’s unclear if the product being built will be a winning solution, so there is a natural tension to limit the amount of investment made to get the product to market to test it. I am also a huge believer in the value of [constrained capital](https://matthewgoldman.com/the-value-of-capital-constraints/?ref=productftw.com), which drives creative solutions (necessity being the mother of invention, and all). If you don’t have an external deadline or a clear definition of your milestone versions, you could be stuck in build mode forever. For decades, I have been arguing with clients and business leads about whether a product is “ready” or not. If we go back to basics, these products are designed to solve a problem. So, we need to figure out what the simplest version is that solves the problem. I’m not sure that a skateboard really solves the problem of “I need to go somewhere fast with stuff,” and it’s a bit silly of an example, so I’m going to use Wallaby as my example. # Wallaby 1.0 ![](https://www.productftw.com/content/images/2025/07/IMG_0038.jpg) The core problem the Wallaby app was trying to solve was “I can’t remember which credit card to use at which store to maximize my points.” The solution was to tell people which card, amongst those in their wallet, to use at a store as they were standing at said store (it was an iPhone app to start). To do this, we needed to know: - Which cards were in their wallet - How each of those cards worked - Where they were shopping - What type of merchant it was We also felt that for version 1.0, people needed to be able to log in and save their data. That’s the MVP (or initial launch). We had a few key components: 1. Sign-up/Login (Authentication) 2. Wallet Building (Picking Cards) 3. Card Database 4. Geo-location Services 5. Recommendation Pages We made a lot of shortcuts in each area: 1. Authentication - you couldn’t change your password or email address 2. Picking cards - this just worked poorly! 3. Card database - we started with 600 cards, but in reality, we needed 2,000 (we didn’t know) 4. Geo-location - this worked OK, but we were guessing at a lot of categorization 5. Recommendation pages - we didn’t explain the recommendation, we just gave it The app was embarrassing in some ways. Who ships an app without the ability to change your password? Me! We were totally overwhelmed upon launch with “I can’t find my card” and “You don’t have my card.” Some of this was due to the bad search in wallet building and some due to the small card database. (Not only was the app an MVP, but so was the admin tool. It took 20 minutes to add a new card to the database, which was such a problem that the whole team pivoted for a week to improving the admin workflow of adding new cards.) Wallaby 1.0 was a great initial launch, though. We had thousands of users out of the gate and a ton of feedback and data to learn from. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Tiny Solutions Wallaby 1.0 was successful because, for most users, it solved the core problem. It was missing enhancements (or even basics, like "change password"), but it **did** recommend the best card to use at the store at which you were shopping. We were able to add those other features rapidly and build much more complexity, responding to our users' needs over time. (Did you know that many people want to value their points differently than we did? We didn’t. We built it later, though.) So when you’re thinking about how to align your team against the MVP (or whatever *you* call it), be ruthless about focusing on solving the user’s problem in the smallest way possible and ignoring some of the things you normally feel you must have. You can always add them later. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### The Importance of Working Agreements - ProductFTW #60 URL: https://www.productftw.com/productftw-60-the-importance-of-working-agreements/ Last updated: 2026-05-22T02:26:30.000Z Working agreements are one of the most underrated tools for improving collaboration between product and technology teams. They establish clear expectations, reduce friction, and create a shared understanding of how work gets done. A strong working agreement ensures that teams speak the same language, define success in the same way, and know how to communicate effectively. I have seen firsthand how misalignment between product and technology teams can slow down progress. One of the most common issues is when there is no shared definition of done. Product may think a feature is complete when it has been developed, but engineering may still need to conduct performance testing, deploy it to production, or clean up technical debt. Without an agreed-upon definition of done, teams constantly find themselves at odds over whether work is actually finished. Similarly, a definition of ready is just as important. If engineering starts working on a feature before product requirements, designs, or technical specifications are fully fleshed out, it can lead to delays, rework, and unnecessary back-and-forth. When teams agree on what “ready” means before work begins, they minimize blockers and set themselves up for success. But working agreements go beyond defining when work starts and ends. They shape how teams communicate, collaborate, and operate together. They ensure that teams are aligned not just on what they are doing, but how they are doing it. ![An animated-style illustration of a diverse group of professionals gathered around a modern office table. They are actively discussing and taking notes, with some gesturing towards a whiteboard behind them filled with diagrams, bullet points, and communication strategies. The team members appear engaged and collaborative, representing effective teamwork.](https://www.productftw.com/content/images/2025/10/Dall-E-Working-agreements.webp) I don't think it needs to be this confusing, but you get the idea. # Why Working Agreements Matter A well-crafted working agreement helps teams: - Reduce confusion by establishing clear expectations for how work is done. - Improve efficiency by removing unnecessary friction in decision-making. - Create transparency around priorities, dependencies, and progress. - Align teams by ensuring everyone is working toward the same goals. Without a working agreement, teams default to their own assumptions about how things should be done. That might work in a small startup with just a few people, but as teams grow, misalignment starts to create delays, misunderstandings, and frustration. One of the biggest benefits I have seen from implementing a working agreement is having a common language. Every company, product, and industry has its own terminology, and if teams are not aligned on what certain terms mean, miscommunication becomes a regular occurrence. For example, I have worked at companies where “customers” meant end users and others where “customers” meant business partners. If these definitions are not clarified upfront, teams end up talking past each other. Creating a shared dictionary of key terms as part of a working agreement helps eliminate unnecessary confusion. # Defining “Ready” and “Done” One of the most practical ways to use a working agreement is by establishing clear definitions of ready and done. **Definition of Ready: When is a task ready to be worked on?** - Product requirements are clearly documented. - Designs are finalized and approved. - Error states and edge cases are defined. - Backend dependencies are identified and documented. - No major unanswered questions remain. If any of these are missing, the work is not ready to be pulled into development. This prevents teams from starting work on incomplete tasks, only to hit roadblocks that could have been avoided. **Definition of Done: When is a task considered complete?** - The feature is fully developed and has passed all functional tests. - Performance and security checks have been conducted. - Documentation has been updated. - The feature has been successfully deployed to production. - Any necessary monitoring or alerts have been set up. A common mistake is assuming that work is done as soon as the code is written. A proper definition of done ensures that teams do not just build something, but they deliver a complete and functioning product. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Standardizing Communication and Collaboration Another critical aspect of a working agreement is defining how teams will communicate and document work. - **Where is documentation stored?** Product specs might live in a product management tool, while technical documentation may be in GitHub. Teams need to know where to find key information. - **How are questions asked?** Is Slack the primary tool for quick discussions? Should certain topics be addressed in a weekly meeting? - **When should teams use synchronous vs. asynchronous communication?** Urgent topics might need a live meeting, while non-urgent questions should be documented for review later. I have noticed that communication preferences vary widely based on past experiences. Someone coming from an enterprise background might default to email, while a startup veteran may expect everything to happen in Slack. Without setting expectations, people may unintentionally frustrate each other just by using the wrong communication channel. I have also worked with teams where Slack threads were a mess, and important information got buried. A simple guideline like “keep Slack conversations in threads and summarize decisions in a shared document” can drastically improve clarity and prevent miscommunication. # Meeting Culture and Remote Work Norms Meetings are another area where working agreements help eliminate unspoken expectations and cultural differences. - **Should cameras be on during meetings?** Some teams expect video to be on at all times, while others leave it optional. - **What is considered “on time” for a meeting?** In some companies, people routinely show up 5-10 minutes late, while others expect meetings to start at the exact scheduled time. - **Is multitasking acceptable?** Some teams have a strong expectation that attendees are fully present, while others assume that people will work on other tasks during meetings. At one company I worked at, being late was normal. The campus was so large that people were constantly walking between buildings, and meetings were often back-to-back. It was understood that people would arrive 10-15 minutes late. But in a remote-first company, that same habit would be seen as disrespectful. A simple conversation about what is considered acceptable prevents misunderstandings and frustration. If a company values full engagement in meetings, then establishing that, for example, “no multitasking unless it is directly related to the discussion” can help set the right expectations. # Making Working Agreements a Living Document A working agreement is not something you create once and forget about. It should evolve as the team grows, the product changes, and new challenges emerge. I have found it helpful to review working agreements quarterly and ask: - Are there new challenges that should be addressed? - Are there areas where communication is breaking down? - Are teams following the agreement, or does it need adjustments? By keeping the document up to date, teams stay aligned as they scale. # Setting Teams Up for Success At its core, a working agreement is about helping teams work efficiently with as little friction as possible. It is not about creating rules for the sake of rules. It is about ensuring that everyone has a shared understanding of how they work together. Too often, teams assume that alignment happens naturally, but it does not. Small misunderstandings turn into bottlenecks, simple miscommunications cause unnecessary frustration, and vague expectations lead to wasted time. Taking the time to establish a clear working agreement ensures that teams are set up for success, expectations are clear, and collaboration is smooth. When done right, it is one of the most valuable tools a company can use to create a high-functioning and engaged team. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### The Nine-Box Matrix - ProductFTW #59 URL: https://www.productftw.com/productftw-59-the-nine-box-matrix/ Last updated: 2026-05-22T02:07:35.000Z When I first became a manager of a large team, I found it difficult to assess where each team member stood without comparing them directly to one another. Every individual had different strengths, weaknesses, and potential for growth, but figuring out how to evaluate their progress and make objective decisions about development was a challenge. That was when a mentor of mine, Matthew, introduced me to the Nine-Box Matrix, a framework originally developed by McKinsey to help leaders evaluate employees based on both performance and potential. At first, I resisted the idea of putting people into boxes. It felt like I was reducing individuals to a grid. But after working with it, I realized that this framework is not about labeling people. It is about understanding where each person is and how to coach them toward growth. Now, when I work with clients, I encourage them to use this matrix because it provides a structured way to evaluate talent, set expectations, and determine how to invest in employees. It is not just about identifying top performers. It is about understanding where everyone fits and what actions you, as a manager, need to take. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # What is the Nine-Box Matrix? The Nine-Box Matrix is a talent assessment tool that helps managers evaluate employees based on two dimensions: 1. **Performance**: How well the employee executes their work, whether they exceed expectations, meet expectations, or consistently underperform. 2. **Potential**: The employee’s ability to grow, take on more responsibility, adapt to change, and develop into future leadership roles. These two dimensions create a three-by-three grid, with employees being placed into one of nine categories: ![The image is a 3x3 performance-potential matrix used for talent assessment. The horizontal axis represents performance levels, labeled as "Low Performance," "Moderate Performance," and "High Performance." The vertical axis represents potential levels, labeled as "Low Potential," "Moderate Potential," and "High Potential."](https://www.productftw.com/content/images/2025/03/9-box-talent-matrix-2.jpg) Image credit to Indeed.com Understanding where employees fall in this matrix allows managers to make informed decisions about coaching, training, promotions, and succession planning. # Why the Nine-Box Matrix is Valuable for Managers What I like most about this framework is that it shifts the focus away from simply ranking employees against each other and instead helps you assess what actions you need to take as a manager. Most employee issues are not just about the individual. They are often the result of lack of coaching, unclear expectations, poor motivation, or external stressors. Instead of immediately assuming that someone is a bad fit, the Nine-Box Matrix helps identify where intervention is possible and how to support growth. Here are a few ways this framework helps managers: - **Clarifies where each team member stands:** Instead of a vague sense of who is excelling or struggling, the matrix provides a clear picture of each person’s position. - **Creates a coaching and development strategy:** Every placement in the matrix should be followed by an action plan. Whether it is mentorship, training, new challenges, or compensation adjustments, this tool helps drive personalized development plans. - **Avoids promoting the wrong people**: Not everyone who is high-performing is a future leader. Someone who has already reached their peak may be better suited for a specialist role rather than management. - **Encourages managers to take responsibility:** If someone is underperforming, the first step is not replacing them. It is asking, "Have I given them the tools to succeed?" More often than not, performance issues can be addressed with better coaching, clearer expectations, or more support. # Breaking Down the Nine Boxes Each of the nine placements in the matrix tells a different story about an employee’s current state and future potential. **1\. High Potential, High Performance: Future Leaders** These employees exceed expectations and continuously improve. They are growth-oriented, adaptable, and take on challenges. Next Steps: Invest in leadership training, stretch assignments, or opportunities to take on more responsibility. **2\. High Potential, Moderate Performance: On Their Way Up** These employees have strong potential but need further development. They may need coaching or time to gain experience. Next Steps: Offer mentorship, skill-building opportunities, or assignments that challenge them. **3\. High Potential, Low Performance: Untapped Talent** These employees have the ability to grow but are struggling in their current role. The issue could be motivation, unclear expectations, or external challenges. Next Steps: Identify what is holding them back. Provide targeted support and set clear expectations. **4\. Moderate Potential, High Performance: Strong Contributors** These employees excel in their roles but may not have the ability or desire to move into leadership. They are valuable, even if they are not future executives. Next Steps: Provide recognition and stability. Keep them engaged through meaningful work. **5\. Moderate Potential, Moderate Performance: Steady but Limited Growth** These employees are consistent but do not show rapid improvement or growth potential. Next Steps: Determine if they are happy where they are or if they need motivation to grow. **6\. Moderate Potential, Low Performance: Needs Improvement** These employees are struggling, but they may be able to improve with coaching and motivation. Next Steps: Work with them on skill-building, set clear goals, and provide direct feedback. **7\. Low Potential, High Performance: Reliable but Limited Growth** These employees deliver excellent work but are unlikely to take on larger roles. Next Steps: Ensure they feel valued and are given responsibilities that match their strengths. **8\. Low Potential, Moderate Performance: Consistent but Not Growing** These employees meet expectations but do not go beyond that. They are steady contributors but unlikely to advance. Next Steps: Keep them engaged in meaningful work, but do not expect leadership growth. **9\. Low Potential, Low Performance: Potential Exit** These employees struggle to meet expectations and do not show growth potential. Next Steps: If coaching and feedback do not lead to improvement, it may be time to consider a role change or separation. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # The Nine-Box Matrix is a Tool, Not a Judgment The most important thing to remember about the Nine-Box Matrix is that it is not a final verdict on an employee’s worth. It is a tool for identifying how you, as a manager, can help each person succeed. A low-performing employee may not be struggling because they are bad at their job. They may need better training, clearer expectations, or a role that better aligns with their strengths. Likewise, a high performer may have hit their ceiling and need a new challenge to stay engaged. When used correctly, the Nine-Box Matrix helps managers make objective, fair, and strategic decisions about their teams. It pushes leaders to think beyond performance alone and consider how to develop, motivate, and retain talent in the long term. Good management is not just about identifying top talent. It is about unlocking potential wherever it exists. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### The Unhappy Path - ProductFTW #58 URL: https://www.productftw.com/productftw-58-the-unhappy-path/ Last updated: 2026-05-22T02:26:25.000Z When building products, it is easy to focus on the happy path. The happy path is the ideal scenario where everything works as expected and the user moves seamlessly from point A to point B. It is the experience we hope for, the one we test most thoroughly, and often the one that defines the core product requirements. But real users do not always follow the happy path. Systems fail, inputs are incorrect, connections time out, and users make mistakes. These failures create friction, and without proper handling, they can lead to frustration, churn, or even broken functionality. That is where the unhappy path comes in. The unhappy path is what happens when things go wrong. It is the set of scenarios where errors occur, where users are confused, or where external dependencies fail. While the happy path tells us what needs to happen for success, the unhappy path reveals all the gaps that need to be addressed to make the product resilient, intuitive, and trustworthy. Thinking through the unhappy path is not just an exercise in error handling. It is a core part of building a strong product experience. ![A man stands at a fork in the road, facing the wider path on the right. The left path is narrow and leads to a bright, cheerful landscape with rolling green hills, sunshine, and a rainbow. The right path is wide but dark and stormy, with heavy rain, lightning, and obstacles. The man appears to be contemplating his choice.](https://www.productftw.com/content/images/2025/03/DALL-E-2025-03-06-15.02.12---An-animation-style-image-of-a-man-standing-at-a-fork-in-the-road.-The-left-path-is-narrow-but-leads-to-a-bright-and-happy-landscape-with-sunshine--rol.webp) He already knows what path he is taking # How to Identify the Unhappy Path One of the best ways to uncover the unhappy path is by using flowcharts to visually map out user journeys. Flowcharts help break down the different steps in a process, making it easier to identify points of failure. I like to approach flowcharting with two perspectives: 1. I map out the happy path. I document the steps of an ideal experience where nothing goes wrong. This creates the baseline product requirements needed to build a feature under perfect conditions. 2. I go back and think about where things can fail. I look at every step and ask, what could go wrong here? Does this require an external system? Does this step involve user input? What happens if that input is incorrect? What happens if the system does not respond? This method ensures that failure scenarios are surfaced early, rather than as an afterthought. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Common Areas Where the Unhappy Path Appears The unhappy path exists everywhere, but there are a few areas where it is especially important to think through: **1\. User Input Errors** Users do not always enter data correctly. They mistype email addresses, leave required fields blank, or format phone numbers incorrectly. If the system does not handle these errors well, it can create frustration. - Are error messages clear and actionable? - Does the user get helpful suggestions to correct the issue? - Is there validation to prevent incorrect inputs before submission? A well-designed form does not just reject bad inputs; it guides users toward fixing them. **2\. System and API Failures** Many products rely on external services, whether it is an API for authentication, a payment processor, or a third-party data provider. These services fail more often than we realize. - What happens if an API call times out? - What happens if a response is malformed? - Does the system retry automatically? If the product cannot gracefully handle an API failure, users may be left with confusing errors, lost progress, or broken functionality. **3\. Edge Cases in Workflows** Some users take paths you did not anticipate. They refresh a page mid-transaction, they double-click a button, they navigate away and return later. - Can users resume where they left off if they leave and come back? - Are actions idempotent, meaning they do not accidentally trigger twice? - Do users get stuck in an unintended state? Building for edge cases prevents broken experiences that frustrate users and lead to support tickets. **4\. Permission and Access Issues** Many products have role-based permissions or account restrictions. The unhappy path happens when a user tries to access something they should not or does not have the correct permissions for an action. - Does the system clearly communicate why access is restricted? - Can users request the appropriate permissions if needed? - Is there a fallback experience that still allows them to use the product in a limited way? Users should never be met with a blank screen or a cryptic error message when they do not have access. **5\. Payment Failures and Billing Issues** If your product has subscriptions, transactions, or invoicing, handling failures properly is critical. - What happens if a credit card is declined? - How does the system handle expired payment methods? - Does the user get a clear and timely notification to fix the issue? Billing errors are one of the fastest ways to lose a customer, so they should be designed with care. # Turning Unhappy Paths into Stronger Product Experiences Once you identify the unhappy path, the next step is designing how the system should handle it. There are three key principles to keep in mind. **1\. Provide Clear and Actionable Error Messages** Users should always understand what went wrong and what they need to do next. Bad error messages: - “Invalid input.” (What input? What is wrong with it?) - “Something went wrong.” (That is not helpful.) Good error messages: - “The phone number must be in this format: (123) 456-7890.” - “Your session has expired. Please log in again.” A well-written error message can mean the difference between a user fixing the issue and moving forward or getting frustrated and abandoning the product. **2\. Offer Recovery Paths** When something goes wrong, users should have a way to recover. - If an API call fails, retry it or provide an alternative way to continue. - If a form submission is invalid, highlight the specific fields that need fixing. - If a user gets locked out, offer ways to reset their access. The best products do not just catch errors. They help users get back on track. **3\. Log and Monitor Errors** Even with the best planning, unhappy paths will still happen. That is why it is important to have monitoring in place to track failures in real time. - Use error tracking tools like Sentry or Datadog to log unexpected failures. - Monitor API response times and success rates to catch slow or failing integrations. - Look at user behavior analytics to see where users are getting stuck. If you are not tracking errors, you are only hearing about them when users complain, and by that point, it is already a problem. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Why the Unhappy Path Should Be a Priority It is easy to focus on designing for when everything goes right, but the reality is that things will go wrong. Users will enter incorrect information. APIs will fail. Edge cases will surface. A product is only as strong as its ability to handle failure gracefully. The best way to think about the unhappy path is proactively rather than reactively. Flowcharts, error tracking, and thoughtful UX design all help ensure that when users encounter issues, they do not feel abandoned. A well-handled unhappy path is not just a defensive measure. It can differentiate a product by making it feel robust, reliable, and user-friendly even in imperfect situations. The best products are not just the ones that work perfectly under ideal conditions. They are the ones that support users through every possible scenario, even when things do not go as planned. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### The Ten Questions I Always Ask Myself as a Product Manager - ProductFTW #57 URL: https://www.productftw.com/productftw-57-the-ten-questions-i-always-ask-myself-as-a-product-manager/ Last updated: 2026-05-22T02:07:34.000Z Recently, I was mentoring a new product manager, and I realized that every time I receive a request, whether it is a new feature, an enhancement, or even a bug fix, I instinctively run it through a mental checklist of ten questions. These questions help me decide whether it is worth investing more of my time into and, more importantly, whether it is worth the business’s time. Product management is about making trade-offs. Every decision has an opportunity cost. If you say yes to one thing, you are saying no to something else. Having a structured way to evaluate requests helps avoid wasted effort and ensures that your time is spent on the most impactful work. ![A simple, animated-style illustration of a large balance scale. On one side, a person stands holding a megaphone, appearing to speak loudly. On the other side, a man sits at a computer, focused on his screen. The scale is evenly balanced, representing a contrast between communication and concentration.](https://www.productftw.com/content/images/2025/03/DALL-E-2025-03-03-17.04.40---An-animated-style-image-of-a-large-balance-scale.-On-one-side--a-person-stands-holding-a-megaphone--speaking-loudly.-On-the-other-side--a-man-sits-at-.webp) Find the balance! ## Here are the ten questions I always ask myself before deciding to invest in a new request. **1\. Will this feature be used by more than one customer?** The first thing I want to know is whether this request serves one customer, multiple customers, or all customers. If it is something that only benefits a single customer, I need to consider whether it is truly a one-off request or if it represents a broader need. A good rule of thumb is that product development should focus on scalable solutions. If a request is too specific, it may be better suited for a custom implementation or a support workaround rather than core product development. **2\. What will the impact be if we enable it?** A feature might be interesting, but I need to understand why it matters. Will it help users achieve their goals faster? Will it generate revenue? Will it improve retention? If the impact is unclear or minimal, it is probably not a priority. Every request should tie back to a measurable outcome, whether it is business value, customer satisfaction, or competitive differentiation. **3\. What will the impact be if we do not enable it?** Just as important as knowing the potential benefits of a request is understanding the consequences of not doing it. Will customers churn? Will it cause frustration? Will we lose a potential partnership? Sometimes, the urgency of a request is not about the value it adds but about the risk of not doing it. If failing to implement something could damage trust, cause operational issues, or create compliance problems, it might move up the priority list. **4\. Does this feature make our product more competitive, or are we just keeping up with the market?** There is a difference between a feature that makes the product more competitive and a feature that just keeps us on par with competitors. Both can be important, but they should be weighed differently. If we are falling behind market expectations, that is a problem. A lack of expected features can make us look like a weaker option in the market. However, if we are just copying a competitor’s feature, we need to ask whether it is worth the effort. The best investments are in features that set the product apart, not just maintain feature parity. **5\. How does this affect existing users? Does it create friction or improve usability?** A product change can have unintended consequences on the user experience. A new feature might solve one problem but introduce friction somewhere else. I always consider how this will feel from the user’s perspective. Will this make their workflow easier or more complicated? Will it introduce new confusion or frustration? A feature that technically works but creates user friction is not a good investment. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **6\. Does this align with the product strategy?** No matter how compelling a request might be, if it does not align with the long-term product strategy, it is likely a distraction. Product roadmaps are built around core business objectives, and every new investment should fit into the bigger picture. If something feels out of place, I ask myself whether the strategy needs to evolve or if the request is simply not a priority right now. **7\. Is it a quick win or a major lift? If it is complex, does it justify the effort?** Every team has limited resources. That is why I always consider the level of effort required to implement something versus the expected value. - If something is a quick win and delivers clear value, it is usually worth doing. - If something is a major lift, I need to weigh it against other priorities. Some complex projects are worth the investment, but if a request is a high effort with low impact, it is an easy decision to say no. **8\. If we build this, will it scale well across partners and future iterations?** A feature might solve an immediate problem, but I always ask whether it will scale over time. - Will this feature be flexible enough to support future use cases? - Will it require ongoing maintenance and support? - Will adding this feature create technical debt that will slow down development later? A feature that only works in a narrow context may not be worth the investment unless it is absolutely critical. **9\. Will this create risk for us? If yes, how much risk, and can we control it?** Some requests introduce risk. That risk could be security concerns, performance bottlenecks, or unintended user behavior. - If the risk is high but manageable, I ask whether we have the right controls in place. - If the risk is too unpredictable, it may not be worth pursuing. Understanding risk tolerance is a key part of making informed decisions. **10\. Will this require a legal or compliance review?** Because I work in fintech, legal and compliance considerations are always top of mind. If a change has regulatory implications, we need to bring in compliance teams early. Legal and compliance reviews can introduce long feedback loops, so the sooner we identify the need for their involvement, the better. This question might not be as relevant in every industry, but for regulated businesses, failing to account for compliance early can lead to delays, legal issues, or even blocked releases. ## Why These Questions Matter Every product manager faces constant requests from customers, stakeholders, and internal teams. Saying yes to everything is impossible, and without a clear decision-making process, it is easy to get pulled in too many directions. These ten questions help me filter requests efficiently. If a request does not hold up against these questions, it is probably not worth the investment. If it does, it allows me to move forward with confidence. At the end of the day, good product management is about focus. It is about knowing which opportunities are worth pursuing and which ones are distractions. The best product teams are not the ones that build the most features. They are the ones that build the right features. Whether you are a new product manager or have been in the role for years, having a structured way to evaluate requests can help you prioritize with clarity, push back when necessary, and ensure that every decision contributes to meaningful progress. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### The Importance of Release Notes - ProductFTW #56 URL: https://www.productftw.com/productftw-56-the-importance-of-release-notes/ Last updated: 2026-05-22T02:26:28.000Z As a product manager, you are responsible for ensuring that your product is delivered, executed, and communicated effectively. While the engineering team focuses on technical tasks within a sprint, you are the closest to understanding what is being delivered from a user perspective. That means you are also responsible for translating those changes into something meaningful. Release notes are one of the most important ways to communicate changes to both internal teams and external users. They provide clarity on what has changed, allow internal teams to prepare for customer questions, and help users stay engaged with your product. When done well, release notes serve as both an informational tool and a marketing tool. They show users that the product is evolving and improving while giving them the confidence that they can rely on it. However, release notes are often treated as an afterthought. I have seen countless updates from partners where the release note was nothing more than a single vague sentence, giving little insight into what actually changed. If a release note does not provide enough detail to be useful, it might as well not exist. Writing good release notes requires thoughtfulness. They should tell a story, excite users, and explain the 'why' behind the changes. Even minor updates deserve context. If an API field was removed, was it because of technical debt? Was it rarely used? Was it replaced with something better? These details matter. ![A cartoon-style illustration of a man standing on a stage, facing the audience, holding an extremely long piece of paper that extends off the stage. He has a surprised expression as he reads from the endless sheet. The background is plain with soft lighting, and the stage is simple and unadorned.](https://www.productftw.com/content/images/2025/03/DALL-E-2025-03-03-16.52.49---An-animated-style-image-of-a-man-standing-on-a-stage--holding-a-very-long-piece-of-paper-that-extends-all-the-way-off-the-stage.-The-perspective-is-fr.webp) Albert Einstein once said, if you can't explain it simply then you don't understand it. # What Should Happen Before and After a Release Release notes are just one part of a larger release process that should happen once a product is in production. A structured release process ensures that internal teams are prepared and that external users have everything they need to understand and adopt new features. A well-organized release process typically includes: 1. **Internal Communication Before Release** 1. The first step is making sure that internal teams are informed before an update goes live. Customer support, sales, marketing, and other stakeholders should be aware of what is changing so they can handle questions from users. 2. Internal documentation should be updated in advance so that teams can reference it when needed. 2. **Preparation of Supporting Documentation** 1. Any user-facing changes should be supported with clear documentation, FAQs, and troubleshooting guides. If a feature is changing, users need to know how to adapt. 2. For API changes, technical documentation should be updated and include examples of how to use the new functionality. 3. **Public Release and Distribution of Release Notes** 1. Once everything is in place, the update is released, and release notes should be published. 2. Release notes should be accessible in multiple formats, whether through in-app notifications, emails, or a dedicated release notes page. When release notes are part of a structured process, they help teams work efficiently and create a smoother user experience. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # What Every Good Release Note Should Include A well-written release note should be clear, informative, and engaging. Industry best practices suggest including the following elements: - **Header:** Clearly state the product name, version number, and release date so users immediately understand what the update applies to. - **Overview:** Provide a short summary of the key changes to help users quickly understand the biggest improvements. - **Detailed Descriptions:** Break down individual updates, including new features, enhancements, bug fixes, and API changes. Use clear language to describe what has changed and how it impacts the user. - **Impact and Next Steps:** Inform users if they need to take any action, such as updating settings, migrating to a new API, or adjusting workflows. - **Visual Aids:** Whenever possible, include screenshots or short videos to help illustrate the changes. This is especially useful for UI updates. - **Contact Information:** Provide a way for users to reach out with questions or feedback. This could be a link to customer support, a forum, or a feedback form. Companies that do this well include Webflow, Linear, and Timeular. Webflow categorizes updates by feature and enhancement while using tags for clarity. Linear and Timeular structure their release notes on a single page with sections for features, improvements, fixes, and API changes. This level of organization makes it easy for users to quickly find relevant updates. # Minor Updates vs. Breaking Changes One of the biggest responsibilities when managing a release is understanding whether a change is a minor update or a breaking change. The difference determines how much notice you need to give users and how you communicate the update. - **Minor Updates:** These are backward-compatible improvements that do not require any action from the user. Examples include adding optional parameters to an API, fixing minor bugs, or improving performance. Minor updates can usually be announced at the time of release without advance notice. - **Breaking Changes:** These are updates that are not backward compatible and may disrupt users or require them to take action. Examples include removing a feature, changing an API response format, or altering system behaviors in a way that requires users to update their integrations. Breaking changes should be communicated well in advance, typically with at least 90 days’ notice, but this can vary based on the industry. Failing to clearly communicate a breaking change can lead to frustrated users, broken workflows, and unnecessary support tickets. If users know what is coming, they can plan accordingly. # The Role of Release Notes in Building Trust Release notes are not just about listing changes. They are an opportunity to build trust with users by showing them that the product is continuously improving. Users should feel confident that they will always know what is changing and why it matters. Good release notes: - Show that the company is invested in making the product better - Provide transparency into what is happening behind the scenes - Make users feel like they are part of the product’s evolution A company that communicates poorly through release notes can erode user trust. If updates are unclear or undocumented, users may feel that changes are being made arbitrarily. Even worse, they may miss out on valuable new features simply because they were not properly informed. # Release Notes as a Product Practice It is easy to dismiss release notes as just another administrative task, but they are a core part of delivering a great product experience. They keep internal teams informed, help users get the most out of new features, and create excitement about the product’s progress. I have worked with many partners where release notes were nothing more than a vague line item that provided little value. However, I have also seen companies like Webflow, Linear, and Timeular use release notes to engage users and showcase the work being done. The difference is significant. The best release notes are thoughtful, well-structured, and easy to understand. They do not just list changes. They explain why the change was made and how it benefits the user. Even the smallest updates deserve attention. A good product manager does not just think about what is being built; they also think about how it is communicated. Release notes are an extension of that philosophy. When done well, they are not just documentation; they are a powerful tool for user engagement, trust, and transparency. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Why I Am Not the Biggest Fan of GraphQL - ProductFTW #55 URL: https://www.productftw.com/productftw-55-why-i-am-not-the-biggest-fan-of-graphql/ Last updated: 2026-05-10T23:40:44.000Z I am not the most technical person. My focus is on product development, but I make it a point to dip my toes into the technical landscape so that I can ask the right questions, challenge assumptions, and ensure feasibility before committing to a feature. Recently, I have been working with partners who have switched from REST to GraphQL. While I understand why GraphQL is powerful, I have come to realize that it presents unique challenges from a product management perspective. GraphQL is flexible, allowing you to pull only the data you need instead of making multiple API calls. Instead of five separate requests, you can retrieve everything in one efficient call. That is great in theory. But in practice, it requires an entirely different way of thinking, and if not managed well, it can create complexity rather than reducing it. From a product development standpoint, GraphQL introduces friction that REST does not. It makes early-stage product scoping more difficult, forces teams to rely heavily on accurate technical documentation, and increases the initial startup cost of development. ![An animation-style illustration of a woman sitting at her desk, trying to untangle a bundle of wires. She has a focused yet slightly frustrated expression. The desk is cluttered with electronic devices and tangled cables.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-26-16.01.10---An-animation-style-illustration-of-a-woman-with-blonde-hair-and-a-fringe--wearing-pink-glasses-and-a-black-shirt--sitting-at-her-desk.-She-is-trying-t.webp) Don't get trapped in the complexities! # The Product Challenge: The Need for Clarity in Early Development When writing product requirements, I focus on what the product needs to do, not how the technology should implement it. That is the job of my engineering counterparts. But with GraphQL, that line becomes blurred. With REST, my team can take my requirements and test API calls directly to see what the API can and cannot do. This means we can immediately identify gaps between what we want and what is possible. With GraphQL, that early discovery phase becomes much harder because it is so flexible. Instead of receiving clear-cut endpoints, developers need to construct their queries from scratch, deciding which fields to request and how the data should be structured. This flexibility means that: - The team has to spend extra time designing API requests rather than focusing on building features. - There is room for misinterpretation, where developers assume certain data is available when it is not. - Product teams are forced to rely on documentation to determine what is possible rather than testing API calls in a straightforward way. If the documentation is lacking or outdated, the entire development process suffers. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # The Documentation Problem: When Flexibility Becomes a Liability One of my biggest frustrations with GraphQL is that it requires teams to fully trust the documentation. Unlike REST, where you can often figure things out by calling a well-defined endpoint, GraphQL demands that you know what you want to return before you start coding. If the documentation is incomplete, unclear, or incorrect, you are stuck. Your team is left guessing how to structure requests, which can lead to: - Inconsistent data formats that break the product experience. - Additional development cycles spent debugging issues that could have been avoided. - Wasted time asking the API provider for clarification instead of moving forward. I have had to explain this challenge to non-technical stakeholders, and the way I put it is simple: “You have to know exactly what you want before you start coding, and you have to trust that the partner’s documentation is accurate. If either of those things fails, your team will fail.” # A Real-World Example: The Phone Number Formatting Problem I ran into this issue firsthand when trying to integrate a client with a third-party API. We were using their GraphQL API, but there was no clear documentation on how to format phone numbers when sending requests. In REST, this would have been obvious—we would send a request, get an error, and immediately see the expected format. With GraphQL, the flexibility meant that: - The API did not reject our request outright; it simply returned incomplete or incorrect results. - We had no way to confirm whether we were formatting the data correctly. - We wasted hours troubleshooting something that should have been self-explanatory. This is a prime example of how GraphQL introduces unnecessary friction in product development. The promise of flexibility comes at the cost of clarity and immediate validation. # The Trade-Offs: When GraphQL is Worth It (and When It Is Not) That said, I do not **hate** GraphQL. I see the benefits, and I understand why teams love it. There are times when it makes perfect sense, such as: - When you are building highly customizable applications that require retrieving different sets of data for different users. - When performance optimization is critical, and reducing multiple API calls to one is a game-changer. - When you have a well-documented API with a strong team that fully understands how to work with GraphQL. However, in early-stage product development, GraphQL introduces more complexity than it removes. The increased startup cost of development, the reliance on documentation, and the potential for misinterpretation make it a difficult choice for teams that need speed and clarity. # How Product Managers Can Work with GraphQL More Effectively For product managers who are working with GraphQL, there are ways to mitigate these challenges. ## **1\. Set Clear Expectations on API Documentation** If you are working with a third-party provider, push for detailed documentation before development begins. Request examples of: - Expected data formats. - Common API queries. - Error handling responses. This will save significant time down the road. ## **2\. Involve Engineering Early** Since GraphQL requires teams to structure queries manually, involve engineers early in the requirements phase. Ensure they have the time to: - Review the GraphQL schema. - Identify potential issues before development begins. - Confirm that what you are asking for is technically feasible. ## **3\. Prototype and Test API Calls Before Finalizing Requirements** With REST, teams often define product requirements first and then see what is possible. With GraphQL, it is better to experiment first. Having a developer test out queries in a GraphQL playground before finalizing the feature scope can help avoid misalignment. ## **4\. Focus on the First 30-60 Days of Feature Needs** If you are launching a new product or integration, focus on what is actually needed in the first 30 to 60 days. GraphQL gives you endless possibilities, but not all of them need to be implemented immediately. Prioritizing what matters will reduce complexity and speed up development. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # Final Thoughts: Is GraphQL Right for Every Team? GraphQL is a powerful tool, but it is not always the right one. For mature products with well-defined data structures and teams that are comfortable writing complex queries, GraphQL can be a game-changer. But for teams working on early-stage product development, it can slow things down, introduce unnecessary complexity, and create frustrating roadblocks. As a product manager, my job is to balance technical feasibility with product clarity. And while GraphQL brings incredible flexibility, that flexibility comes at a cost. At the end of the day, choosing REST or GraphQL is not just a technical decision. It is a product decision, and teams need to consider how it will impact speed, efficiency, and clarity before committing. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### My #1 Interview Question - ProductFTW #54 URL: https://www.productftw.com/productftw-54-my-1-interview-question/ Last updated: 2026-05-22T02:07:32.000Z Hiring the right product manager is a mix of art and science, and for those looking to land a PM role, understanding what hiring managers are looking for can make a big difference in landing an offer. Whether you're hiring or job-seeking, it's important to know what helps a strong candidate to stand out. A great product manager isn’t just someone with a solid resume—they need to think critically, communicate clearly, and drive real impact. Over the years, I’ve refined my approach to product interviews, and there’s one question I always ask because it consistently helps me identify the best talent. ![An animated-style illustration of a job interview scene in a modern office. A woman in a business suit sits across from a man in a suit at a desk. The interviewer holds a clipboard while the candidate listens attentively. The office features large windows, shelves with binders, a clock on the wall, potted plants, and a whiteboard labeled "JOB INTERVIEW" in the background.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-11-14.54.18---An-animated-style-illustration-of-a-job-interview-scene.-A-woman-sits-across-from-a-man-at-a-desk-in-a-modern-office-setting.-The-interviewer-holds-a-.webp) Do you have any questions for me? ## **The Question** *Imagine you’re the product manager for an app you use frequently. What would you change about it and why?* I always use Dropbox as my example because everyone knows what it is and can think critically about how it works. I’ll often say, 'If you were the PM for Dropbox, what would you change and why?' This helps set a clear expectation for how they should structure their answer. But I let candidates pick their own app because I want them to talk about something they actually care about. Their choice gives insight into their interests and how they think about product problems. The goal isn’t for them to pick the 'right' app—it’s to see how they analyze problems, think through solutions, and explain their reasoning. This question opens the door for them to showcase their ability to break down a product, consider user needs, and propose meaningful improvements. ## **Why It Works** This question isn’t just a casual icebreaker—it’s a real test of how a candidate thinks. A strong PM needs to assess user pain points, balance trade-offs, and clearly articulate their thought process. If they can’t do that in an interview, they’ll struggle to do it in the job. It also reveals a lot about their experience and mindset. Do they get stuck on surface-level complaints, or can they dig deeper into why something isn’t working? Can they identify an opportunity and propose a concrete improvement? And, most importantly, can they do all of that while keeping their response clear and engaging? ## **What a Good Answer Looks Like** The best candidates don’t just pick an app—they pick a problem worth solving. Instead of saying, “I think the interface should be cleaner,” a strong answer explains what’s broken, who it affects, and why fixing it would drive meaningful impact. For example, someone might pick Spotify and talk about how the music discovery experience could be improved. They’d explain why the current recommendation algorithm falls short for certain users and walk through a possible solution—maybe a more interactive way to refine recommendations based on mood or past listening behavior. A great answer shows me that they can spot real opportunities, understand user needs, and think strategically about product improvements. Another sign of a strong candidate is if they choose an app that ties into the business they’re applying for. If you’re hiring for an AI-focused company, for example, and they pick an AI product—even if they don’t have direct AI experience—it demonstrates they’ve thought about your industry and are personally interested in it. It shows they’re capable of connecting the dots between your business and their own knowledge, which is a valuable skill in any PM role. ## **Red Flags** Some responses immediately signal that a candidate might not be the right fit. If they struggle to provide a structured response, that’s a red flag—PMs need to be able to organize their thoughts on the fly. If they only focus on their personal frustrations without considering broader user needs, that’s another concern. And if they can’t go beyond vague suggestions like, “I’d make it easier to use,” that’s a sign they may not have the depth of thinking needed for the role. ## **A Memorable Response** One time, a candidate picked Tinder and said, “I just think it’s hard to meet people.” That was their whole answer. No specific problem, no insight into user behavior, no solution. Compare that to another candidate who picked an Airbnb-style service for pools. They identified a major trust and safety issue in the booking process and proposed a well-thought-out fix. The difference in depth was night and day. ## **The Bottom Line** Hiring a great product manager isn’t just about checking boxes on a resume—it’s about finding someone who can think deeply, communicate clearly, and solve real problems. This one question has helped me assess those qualities time and time again. If you’re hiring PMs, try it in your next interview. If you’re a PM looking for a job, be ready for it—you never know when you’ll get asked. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Knowing When to Launch - ProductFTW #53 URL: https://www.productftw.com/productftw-53-knowing-when-to-launch/ Last updated: 2026-05-22T02:26:27.000Z I am known to be a Type A perfectionist, which makes knowing when a feature is truly done a challenge. When it comes to individual features, the decision is more straightforward. If a feature meets its acceptance criteria and aligns with the design, it is a no-brainer to launch it. But when you are putting multiple features together for a full product launch, how do you know when it is *really* time to go live? At Totavi, I focus on implementation, helping clients take financial products from ideation to launch. Right now, I focus primarily on consumer credit, but I have also worked on debit and business products. Large consumer credit products require countless components before they are truly ready, from regulatory approvals to bank compliance, program management, and development execution. Some of these requirements are clear. You either have the necessary policies and procedures in place, or you do not. But when it comes to product readiness, the decision is far more nuanced. Knowing when to launch is about understanding what features must be there from day one versus what can wait. It is about ensuring that core functionality works while acknowledging that not every feature needs to be perfect before launch. ‼️ ****Disclaimer:** The examples and feature guidance shared in this post are intended for general informational purposes only. They do not constitute legal, compliance, or operational advice. If you are building a credit card program, you must ensure that your implementation aligns with your specific credit policy, cardholder agreement, rewards terms and conditions, and all applicable regulatory and partner obligations. Every product decision involves tradeoffs. If you defer a feature (e.g., rewards redemption) but make customer-facing commitments around it, you must have a reliable manual process in place to meet those promises. Skipping technical development may reduce upfront effort but will often increase operational burden, customer support complexity, or compliance risk. Build intentionally. # Balancing Perfection with Practicality Because I have perfectionist tendencies, I always want everything to be fully complete before launch. But the reality is that every day spent waiting is time and money lost. Development is expensive, and the longer you wait to launch, the longer it takes to start learning from real users. A key part of my decision-making process is evaluating what users will actually need in the first 30 to 60 days. For example, when launching a consumer credit product, I ask: - What needs to be enabled for repayment functionality on day one? - How can we handle a lost or stolen card in the first 30 days? - Which redemption options need to be enabled on day one? Compare that to core functionalities like: - The ability to log in - A seamless onboarding flow - The card being fully functional - And more... These are essential at launch. But something like having multiple redemption options can likely wait if users will not accumulate enough rewards within the first month to need redemption. Breaking down early-stage critical features versus post-launch improvements allows you to confidently move forward rather than waiting until everything is perfect. ![A cartoon-style illustration of two engineers in orange uniforms standing in front of a large rocket, preparing for launch. One is holding a clipboard while the other listens. The scene includes communication towers, a fuel truck labeled "ROCKET," a toolbox, and a futuristic industrial backdrop with a wind turbine and a starry sky.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-11-12.07.47---A-cartoon-style-illustration-of-two-people-standing-in-front-of-a-large-rocket--looking-at-a-clipboard--preparing-for-launch.-The-scene-features-a-pla.webp) It's not rocket science! Or is it? # When You Launch Too Early With every launch, there is always a risk that you are going live too soon. No product manager ever wants to launch too early, but it happens. The key is weighing risk versus reward before making that call. A clear example of this was when I was developing a partner portal for a cybersecurity company. We launched the admin panel before the actual functionality existed. The buttons were there, but they did *nothing*. The result? - Confused internal users who thought functionality was broken - Frustrated external users who expected features that did not exist - A huge burden on operations, who had to field unnecessary support requests - Lost trust from customers, which is one of the hardest things to recover from The lesson? If a feature is visible, it needs to work. It is one thing to have missing functionality that users do not know about. It is a whole different problem to promise something that does not exist. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Deciding Launch Readiness Over time, I have developed a structured process to determine when a product is truly ready. Here is how I approach it: 1. Evaluate your original vision versus reality: 1. What did we originally intend to launch? 2. What features were essential in our early planning? 3. What is the long-term vision, and what can be phased in later? 2. Assess feature completion and gaps: 1. What percentage of each core feature is complete? 2. Which features are at risk of delay, and how critical are they? 3. Are there workarounds for missing features, or would users be blocked? 3. Categorize the risks for each missing or incomplete feature and determine the impact: 1. Is this an operational risk that will add extra work for internal teams? If so, can it be mitigated with training or documentation? 2. Will it cause a frustrating user experience? If so, how frustrating? 3. Will it break user trust? If so, launching is probably not a good idea. 4. Could it create technical debt or data integrity issues in the future? This framework allows me to move beyond gut instinct and make structured, data-driven decisions on launch timing. # Aligning Teams Product managers do not just own the product. We also own the communication around launch readiness. It is our responsibility to ensure that everyone involved understands the trade-offs and is aligned on what is shipping. That means: - Engineering knows what must be fully functional versus what is coming later. - Operations and support teams are prepared to handle user impact from missing features. - Compliance and regulatory teams have signed off on all required elements. - Leadership understands the reasoning behind launch timing and feature prioritization. A successful launch is about more than what is built; it is also about how well the organization is prepared to support it. # Knowing When to Launch is a Skill At the end of the day, launching is not about perfection. It is about readiness. As product managers, we are never 100 percent comfortable with a launch. There is always something we wish was a little better. But knowing when to launch comes down to: - Understanding user needs in the first 30 to 60 days - Weighing risk versus impact - Aligning teams on trade-offs - Ensuring that anything visible to users actually works The strongest product managers are the ones who can confidently say, **“This is good enough for launch, and here is what comes next.”** And that confidence does not come from knowing everything is perfect. It comes from knowing you made the right trade-offs to get your product into users’ hands without breaking their trust. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### The Balance Between Product and Technical Leadership - ProductFTW #52 URL: https://www.productftw.com/productftw-52-the-balance-between-product-and-technical-leadership/ Last updated: 2026-10-14T01:25:33.000Z There has been a lot of discussion about whether strong technology leaders or experienced developers can replace product managers, so much so that [Zach](https://www.productftw.com/productftw-18-should-product-managers-be-technical/) and [Todd](https://www.productftw.com/productftw-building-great-product-and-tech-relationships/) both covered the topic last year. I wanted to give my take. While I do believe that a strong technical leader can take on many responsibilities of a product manager, there are limitations to this approach. Product managers are not supposed to dictate how to deliver technology. Their role is to define *what* needs to be built and *why* it matters. A technical leader, on the other hand, fills in the *how*. That is not to say product managers should not be technical. They absolutely should understand enough to challenge their technical counterparts, ask the right questions, and call out issues that seem misaligned with common sense. But they should not attempt to drive technical solutions in a way that compromises scalability, security, or the integrity of the overall architecture. ![An animated-style illustration of two people working together to climb over a tall wall, symbolizing teamwork, perseverance, and mutual support. One person is already on top, reaching down to help the other up. The background features a stylized cityscape with abstract buildings, plants, and a sky with clouds.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-11-15.49.29---An-animated-style-illustration-of-two-people-working-together-to-climb-over-a-tall-wall--symbolizing-teamwork--perseverance--and-mutual-support.-The-c.webp) Two brains are better than one! # When Technical Leaders Take on Too Much of the Product Role I have worked with several technical leaders who took on too much of the product role, and every time the outcome was the same. When a product requirement was complex from a solution standpoint, the technical leader often decided it was not worth it and pared down or reduced the feature. While this approach might have made sense from a development or efficiency perspective, it ultimately hurt the user experience. One particular instance that stands out was when we were developing a feature that required integrating with a third-party tool. From a product perspective, we needed to collect and store a set of user data points to make the integration seamless. However, because the integration was complex and required additional development effort, our tech lead decided to reduce the scope significantly, removing key user inputs. The result was a streamlined backend solution, but a far worse user experience. Users had to manually enter data multiple times instead of having it prefilled from our system. Many technical leaders believe that product managers sometimes create overly complex requirements that do not align with technical constraints. While that *can* be true, it is not always the case. Every time I have seen a technical leader take over the product role, they tend to focus on efficiency and what makes sense for the technologies they already know, rather than considering whether better solutions exist beyond their purview. This is where a strong product and technical partnership becomes essential. A product manager pushes for what is best for the user, while a technical leader ensures that the solution is scalable and maintainable. If one role overtakes the other, you either end up with a highly efficient but suboptimal user experience, or an ambitious feature that does not account for technical constraints. # When Product Managers Are Forced to Make Technical Decisions On the flip side, I have often found myself in situations where I had to make technical decisions I was not qualified to make. I work with a lot of outsourced teams and startups, where strong technical leadership is not always present. In these cases, I am often asked technical questions that require research and guesswork on my part. A perfect example of this came up recently when I was working on an API. I understand how APIs work, and I felt confident in defining the requirements for authentication. From my perspective, it needed to be simple, secure, well-documented, and follow industry best practices. However, my technical counterpart knew that our existing software stack had specific authentication parameters that we needed to abide by. While I might have suggested generating an API key as the best approach, they knew that it would not align with how authentication works across the rest of our system. Without their guidance, I could have introduced inconsistencies or security gaps simply because I lacked the full technical picture. The biggest impact of this is twofold. First, I am not the right person to make certain technical decisions, which increases the risk of poor implementation. Second, it takes me away from my core responsibilities as a product manager, which include defining user needs, ensuring a great experience, and guiding the overall vision. When I spend too much time trying to figure out technical feasibility without the right support, I am less effective in driving the product forward. I still dream about the strong partnerships I had at CreditCards.com and Red Ventures, as well as when I started a company with individuals who deeply understood both technology and product. Two of the best examples of this were Zach and Mitchell, who had an incredible awareness of product and how to solve problems. They understood the importance of product requirements and how to think about the larger picture and strategy. Zach and Mitchell had the ability to take product requirements and see them through a technical lens, bringing solutions to the table without sacrificing time, security, or overcomplicating the build. Working with them was an ideal partnership. I could talk to them as a product manager, explain user and business needs, and they would listen, understand, and translate that into a technical solution. They would then distill it back to me in a way that ensured I was comfortable with the approach, and together we would guide the developers. That is the type of partnership I strive to find in every role, because when you have a technical leader who works *with* you instead of *without* you, everything runs more smoothly. You do not have to worry about whether the API is implemented correctly or whether edge cases have been accounted for. You have a partner who ensures it is handled properly while keeping the bigger picture in mind. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # How Product Managers and Tech Leaders Can Communicate Effectively To avoid friction, product managers and technical leaders need to communicate constantly. They should align on requirements early, discuss trade-offs, and work together to define both the product and technical approach before handing anything off to the team. A great collaboration looks like this: - The product manager defines what the feature needs to do, why it is important, and how success will be measured. - The technical leader provides insight into *how* it can be built, what constraints exist, and what trade-offs need to be considered. - Together, they refine the solution before presenting it to the engineering team, ensuring a shared understanding of both user needs and technical feasibility. The development team should not be expected to define the entire solution on their own. While they should have input and flexibility to solve problems in the best way, it is up to the product manager and technical leader to guide them toward the right approach. # A Real-World Example of Collaboration One example of this collaboration is when I was recently building onboarding for a consumer credit program. During the onboarding process, there are specific fields that must be collected to determine if a person passes Know Your Customer (KYC) checks or credit underwriting. From the product perspective, it is my job to define the following: - What fields need to be collected - What the underwriting criteria should be - What the user experience and flows should look like On the technical side, the tech lead must determine: - How to integrate with a KYC and underwriting provider, such as Alloy - What security measures need to be in place - How to structure the backend to handle application submissions efficiently In this scenario, neither role can operate effectively in isolation. If I, as the product manager, dictated how the integration should be done without understanding the technical constraints, I could create a requirement that is unrealistic or unscalable. If the technical leader dictated the onboarding experience based purely on what is easiest to build, we might end up with an experience that does not meet regulatory requirements or user expectations. By working together, we ensure that both the product and technical perspectives are accounted for, leading to a secure, scalable, and user-friendly solution. # Final Thoughts At the end of the day, product managers and technology leaders bring different, complementary skills to the table. One without the other creates imbalance. A strong product manager ensures that the team is solving the *right* problems for the *right* users in the *right* way. A strong technical leader ensures that the solution is scalable, maintainable, and technically sound. The best products happen when both roles are in sync, respecting each other’s expertise while collaborating toward a common goal. Without this balance, you either end up with a product that is well-architected but not user-friendly or a product that is user-focused but technically flawed. The strongest teams are the ones where product and technical leadership work in true partnership, ensuring that what gets built is not only functional and efficient but also meaningful and impactful for users. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Ten Things That Always Break - ProductFTW #51 URL: https://www.productftw.com/productftw-51-ten-things-that-always-break/ Last updated: 2026-05-22T02:26:26.000Z ![Man in green shirt with his head on a cluttered desk, two monitors showing open screens.](https://www.productftw.com/content/images/2025/07/headdeskopt.jpeg) Actual footage of forgetting to check the list When I built Wallaby with my co-founder, Todd Zino, from 2012 to 2014, we made a list of things that always caused problems. I can’t find the original list, which feels apropos for a piece like this. (Item no. 1: You lose your checklist.) Fintech software is a unique beast. You’re not just building apps; you’re building trust, handling money, and navigating a minefield of technical and regulatory complexity. Here are ten things (plus a few honorable mentions) that frequently go wrong in fintech development, even for the most seasoned teams. I recommend running through this if you’re building something new or trying to troubleshoot. It’s like checking to ensure your computer is plugged in and your power-strip is turned on. # The 10 Things ## 1\. Time Zone (or Time Zone Conversion) Time is a lie. Especially in fintech. Whether you’re calculating interest, triggering cutoffs, or just showing a timestamp to a user, time zone issues can lead to misfires. Daylight saving? Regions that don’t observe it? Systems that assume local time? Chaos. ## 2\. Firewalls, IP Tables, or Security Tools You deployed your app, and everything broke, but it was only in production. Security layers like firewalls, rate limiters, or outbound connection restrictions often block key dependencies (like payment processors or fraud tools). These problems rarely appear in dev environments and are notoriously hard to debug. ## 3\. Off-by-One Errors The sneakiest of bugs. Did that loop include the last item? Did your date range capture the complete end of the day? These tiny mistakes often surface in pagination, balances, or transaction windows, and they can erode user trust quickly when money appears “missing.” ## 4\. Currency Conversion Errors Money math is brutal. Using the wrong rate, applying it in the wrong direction, or rounding incorrectly can lead to frustrating inconsistencies. Things get even trickier with zero-decimal currencies or multi-leg conversions (e.g., JPY → USD → BTC). ## 5\. Pending Transactions Posting Early (or Late, or Never) Banking systems don’t always behave the way users expect. A charge shows up as pending and then vanishes. Or it posts for a different amount. If your app doesn’t explain this nuance well or handles it inconsistently, it quickly breaks user trust. ## 6\. Date/Time Formatting Errors Is that 01/02/2024, January 2, or February 1? Date formatting across locales is a breeding ground for bugs. Add parsing issues from third-party APIs, and you’ve got a perfect storm for transactions getting timestamped — or rejected — incorrectly. ## 7\. Race Conditions in Asynchronous Systems In distributed systems, timing is everything. But weird things happen when two systems try to update the same record — or process the same event — simultaneously. Especially dangerous when dealing with webhooks, ledgers, or stateful workflows. ![Animated microchips in a footrace. One is smiling, the other is not.](https://www.productftw.com/content/images/2025/07/racing-chips.png) *Please don't make your microchips compete.* ## 8\. Decimal vs Float Representation Never use floats for money. Ever. Using floating-point math instead of fixed-point or decimal libraries can cause minor rounding errors that compound, and fractions of a cent matter in fintech. Always use the correct data types. ## 9\. Inconsistent State Between Systems One service thinks a transaction succeeded; another thinks it failed. This kind of data drift can stem from retries, partial failures, or lack of atomic operations — reconciling these mismatches is painful and error-prone. ## 10\. Poor Handling of Retries or Idempotency[\[1\]](#fn1) Retrying an API call without proper idempotency can lead to double charges or duplicate records. Conversely, not retrying when you should can result in dropped or incomplete actions. Fintech systems must be deliberate about handling retries safely. # Honorable Mentions (But wait - there's more!) ## “Just Use the Test Environment”...That Doesn’t Match Prod Sandbox APIs often behave differently from production, causing development teams to miss edge cases entirely. Never assume parity without testing. ## Compliance Reviews That Derail Timelines Shipping a product is hard enough without late-stage rewrites from legal. Building in compliance review early (and often) is key. ## Magical Retry Logic with No Observability Retries are great, until they silently fail. Always log and trace background jobs and failure handling to avoid invisible data loss. ## Too Much Trust in Third-Party APIs Fintech is built on APIs, but brittle dependencies can break your product. Always have fallback logic, health checks, and alerts. ## Shadow Data Drift When your ledger and reporting don’t match, you'll have trouble figuring out where things broke. Keeping a single source of truth (and syncing regularly) is essential. ![Animated Peter Pan trying to catch his shadow, which is climbing off the wall.](https://www.productftw.com/content/images/2025/07/Peter-Pan-and-his-Shadow.jpg) *Peter learned about shadow drift the hard way.* ## Cron (Scheduled) Jobs that Don’t Make it on Time Scheduled jobs are critical in most applications, running maintenance, updating information, and calculating values. These scheduled tasks run in the background and success (or errors) are often logged to logs that no one is looking at. Always document the schedule, scope, and success criteria. Generate loud alerts when they don’t work. ## Audit Tables No One Looks At Audit tables are designed to track when something breaks or fraud slips through. You have to look at them for them to be valuable! Make sure to review audit tables periodically and after each release. Otherwise, I can guarantee the logs will be broken when you need them. # Final Thoughts Fintech teams face a unique blend of engineering complexity, regulatory pressure, and high user expectations. The problems on this list aren’t exotic; they’re common, recurring, and often subtle, and that’s precisely why they deserve attention. Investing time in better observability, defensive coding, and operational discipline can prevent a world of pain down the line and make your product (and your team) far more resilient. Did I miss your favorite fintech bug? Put it in the comments. --- 1. Not sure what the hell idempotency is? Developers love to use this word and PMs love to pretend like they get it. Idempotency means that performing the same action multiple times has the same effect as doing it once. In software, this is crucial for safely handling retries, especially in APIs. For example, if a user tries to make a payment and the network times out, your system might retry the request. If that request isn’t idempotent, you could accidentally charge the user twice. But if it is idempotent, the system recognizes the retry as a duplicate and avoids performing the action again. [↩︎](#fnref1) ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Product Talks with Matthew Goldman - ProductFTW #50 URL: https://www.productftw.com/productftw-50-product-talks-with-matthew-goldman/ Last updated: 2026-05-22T01:57:28.000Z For our final post in the[ Product Talks](https://www.productftw.com/product-talks/) series, we’re featuring Matthew Goldman. Matthew is the Founder of Totavi, a consulting firm focused on fintech, with a career that spans Green Dot, AT&T, Wallaby, Vertical Finance, and Bankrate. Over the past ten years of working together, Matthew has not only become one of my closest friends but also the person who taught me everything I know about product. His approach is clear, hands-on, and methodical. He believes product managers should be embedded in the team, not off in a corner writing strategy docs. He showed me that real product work means writing the documentation, breaking out the tickets, and working closely with engineering every step of the way. He shaped how I think, how I work, and what I believe product management should be. I’m so excited to sit down with him and share his perspective with everyone else. For more of Matthew's product thoughts, see his previous [ProductFTW posts](https://www.productftw.com/author/matthew/). ![](https://www.productftw.com/content/images/2025/05/product-talks-Matthew.png) **Ellen:* Hi Matthew. How are you today?* **Matthew:** I'm lovely. **Ellen:* Could you please state your name and current occupation for the recording?* **Matthew:** My name is Matthew Goldman.I'm the founder of Totavi, a consulting firm for fintech. **Ellen:* How did you get into product management and what career path did you take to become a PM?* **Matthew:** I think I sort of always wanted to be a product manager, but I didn't know what it was. I'd certainly never heard the term growing up or in college or anything. I was working as a strategy consultant at Deloitte straight out of college and trying to find a new job because I didn't like what I was doing. I had always liked working in technology and I had some experience with small technology companies, maybe you wouldn't call them startups because they weren't venture backed necessarily.I was applying to all sorts of random jobs.I applied to be a financial analyst at a company because I was doing a lot of that consulting, a lot of Excel work. Then I got sent this job posting for a product manager at Green Dot, which at the time was probably about 60 people and had just closed their Series B.I didn't really know what it was, but it sounded interesting, like this intersection of business and technology.I applied for the job, magically I got it, and I've sort of been in product ever since. Although I've had, I think, a very nontraditional product experience. I spent very little time as a product manager, doing typical product manager things.Like even at Green Dot, I immediately got re-orged into a title called Manager of Retail Cards. I was not managing the experience but managing the like integrations with our partners and going on sales calls and things. It was very outward facing.It's been a strange path. **Ellen:* Because you've had an untraditional path to product management, how did you know that you were doing that role?Like what did it mean to you to be a product manager versus a manager of retail cards?* **Matthew:** I think titles are funny and people get hung up on them.I have often thought that there's a lot of people these days who have the title product manager and have no idea what the job really is. Luckily, I had worked in the product organization. For the first year I was at Green Dot, I had good mentorship there from both my direct manager and the head of product. I did some traditional things, like I wrote a PRD.I was given a PRD and asked, “Can you write something like this, but for this other project?” I really did a lot of reading and research on what product looked like then.That was an era when people were talking a lot, certainly, about Google's concept of product managers. I tried to just really focus on the essentials of the business strategy and the technology of “what problem are you trying to solve?” We at the time were originally a very traditional structured company with waterfall development and business analysts who worked in technology and who wrote detailed requirements.We weren't doing that stuff as the product team.We were more, like, higher level, I guess you could say. I also had already built my own companies and written software from scratch.I had started a company in college where I was, I guess, the CTO, although I didn't think of myself that way. I came up with the whole product and built the whole thing myself as an individual developer and had to make all those decisions, whether it was design or technology, whatever. It was terribly written.I'm a terrible programmer. But I think those things helped me understand what the job really was, which I still think, most importantly, is understanding the problem to be solved and how you can meet a user's needs. The rest of it is logistics.And whether you do them or someone else on your team does them, whether it's the project management or developer management, those are important aspects, but it's not the core of the issue to me. **Ellen:* Do you have any advice for new product managers?* **Matthew:** I think if you want to get into product, you need to build a product yourself.The entrepreneurial spirit is very important to me, not surprisingly.And while you don't have to start your own business,I think you have to understand the whole thing. Because the people who have the title and are bad at it have learned about it entirely inside large organizations where they don't have enough true responsibility for the outcome. When my boss, a guy named Kostas, hired me at Green Dot, he actually was very funny because he said to me when he offered me the job, “I am not hiring you because you work at Deloitte.I'm hiring you because you've had your own businesses in the past.”I thought, like, what a weird thing to say to me.But I realized later what he was saying was, “I know you can just figure out how to get stuff done and you can make decisions because you’ve had to do it for yourself.”You can be flexible and all those things. A lot of the best hires I've had, whether engineering or product folks in my career, have been people who have had their own side projects. Again, they don’t have to be like businesses. Maybe it’s “I wanted to make an app to do this thing for myself and I went and I did it.” Maybe it's not a great app, but you have to learn all this stuff to get there, right. You have to come outside your silo. If someone came to me and you know, they were in college or whatever and was like, I want to be a PM, I'd say, “Okay, go figure out how to build a piece of software.”Right?Go find a problem that people have, do that research, and actually build the thing; be very hands on. I don't use a lot of the frameworky stuff.I don't tell people to read the Lean Startup playbook or whatever.I don't even know how to do those things.Yeah, I think people get very distracted with business maps and it's a good way to stay busy or something.And I'm sure some people find it helpful, but I'm more like, just go! Just go muddle your way through something and figure it out and build your own style. **Ellen:* You have me thinking a lot about what it takes to actually build a product from start to finish. It's a lot more than people realize, I think.* **Matthew:** Yeah, it's important. We’ve done a lot of training on these things. It’s important to be good at writing a clear user story.But if you can't even understand how to figure out what user problems are, then you don't get to that part.It's great to be able to run a clean sprint with your team.But that's project management.That's part of the job in a corporation.And in big companies, as we've seen, you might have a project manager or a scrum master or whatever helping you with those things.But it only matters if you're building something useful that people want to use or buy or whatever.And everything else is ultimately like noise. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Ellen:* And knowing how to effectively research to know if you're even solving the right problems. Back to what you originally said - start with the problem. What is the right problem to solve? And we've seen that a couple of times recently where people haven't done the research.* **Matthew:** Yeah, I think there's a common saying about people coming up with solutions first.Sometimes the solution might pop into your head, but before you build the product, you have to figure out what is the real thing that that solution is addressing. A lot of people think, “I built this cool thing, I must be able to sell it to people.”And the greatest products are built with a deep understanding of some underlying problem that people were not even aware of as a problem. I think in the fintech world, my favorite example is actually Stripe. Everybody knew that accepting payments online wasn't great, but nobody thought about the problem crisply enough until Stripe to build a great solution to it.We all just accepted it as the way things were.That's the insight about a key problem that might be staring you in the face.Plus, you know, the timing and the execution that makes something successful. **Ellen:* I know it's not your favorite product book, but *It Starts with Why*, if that's the only thing you took away from that book is the title, it's a pretty good starting place to figure out.* **Matthew:** I mean, I don't have an opinion.I never read it. **Ellen:* You didn't read it? I thought you had, and it wasn't your favorite.* **Matthew:** I don't remember it. Maybe that's how much it meant to me. **Ellen:* You’ve definitely read it. I think you even have it in your bookshelf. Anyway, if that's the only thing you take away and that's the only thing you read was the title, that's a pretty good indicator of where you should start with.* *What has been your biggest challenge as a PM and how did you overcome it?* **Matthew:** There are three types of challenges,I think.One is when you try to do something, and you can't figure out how to actually do it.Like with Wallaby, I had a great problem and a great idea but there were external factors that prevented us from doing it. In many ways I think of that as one of my greatest challenges.And the answer was to solve an adjacent problem. There's also challenges like people challenges, and then there's kind of team management challenges.And I think certainly in that vein, I think a lot about the function of being a product manager.Because the Wallaby problem isn't necessarily an execution problem or a tactic problem.It's more external. When we were at Bankrate, we had to transform an organization, and I think that was the biggest challenge.We had a company that did not know how to build software efficiently, as many do not, actually. I'm very cynical.Most companies are quite bad at what they do and survive anyways. Bankrate could not ship product, could not keep the site running, could not reduce costs intelligently through cloud optimization.It couldn't do anything right.It was quite terrifying.Our friend Kamelia, her favorite analogy is we had to rebuild the car while it was driving down the road.We couldn't just stop. That was such a huge challenge. I certainly had some of my lower moments and some of my higher moments. We were able to achieve some really great things, like really rebuild pieces of software and migrate the site to the cloud. My favorite example is Zach’s project. \[Editor: You can read more about this in [Zach’s Product Talks](https://www.productftw.com/productftw-45-product-talks-with-zach-bartholomew/).\] It used to take us 90 minutes to publish a website, which is terrifying.We managed to, in less than a year, change it so we could do it in seconds from Slack, which was totally transformative and a requirement of the business from a compliance standpoint.But getting there was over a year of really hard people and process management and really core product stuff.We had to change how we prioritized, how we built software, how we organized teams, all those things. Which is maybe more product leadership, but definitely the most challenging time of my career in many ways. **Ellen:* The 90 minutes thing still blows my mind. And the fact that you're saying that we had to migrate to the cloud in 2013, it feels really far behind.* **Matthew:** And now, very few people build stuff outside the cloud, although some people are going back to it \[designing outside of the cloud\]. I tell people there are things that are fundamentally cheaper.It's just whether you want to deal with it.I just had this conversation with somebody yesterday, right?Like racking and stacking your own machines, which is actually how I got started in technology as a sysadmin, is fundamentally going to be cheaper at a certain scale.But you also have to have someone who has to do all that stuff and maybe you just don't want to deal with it.Cost optimization is not the only thing; there's also an operational aspect to it. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Ellen:* Yeah, and security benefits, and things like that.What is a lesson that you've learned as a PM that has changed the way you work or think or collaborate?* **Matthew:** I think that one of the key things about being a product manager is that you have to lead through influence.You're normally not everyone's manager and you can't just tell them what to do. I'm afraid a lot of PMs think that this is going to be their life when they take the job, because it sounds fancy. Or there's the famously wrong “you're the CEO of the product” thing, which is one of my least favorites.You have to bring people along and be an influencer. Although I was probably always someone who had some skills for doing that, I did not think of myself that way, like as a salesperson or as someone who would influence others.I realized in product, if I wanted engineering to do something or I wanted design to think about things a certain way, or I wanted to even get my project on the roadmap, I had to bring data and emotion and influence to bear to get an agreement because I wasn't the CEO.I couldn't just say, “oh, go build this." You see that constantly.It's really funny.Even in big companies, you have executives saying, “Well, I don't know if I can convince everyone to do these things.”It's very hard, especially in high paying, high flexibility, high intelligence technology jobs and companies, to just tell people what to do.They don't want to do it unless they think it's a good idea, so you have to bring that forward. And that, I think, affects all parts of people's lives. Whether you have, you know, a partner or teenagers, as I do.Like, you can't just tell them what to do.You have to try to convince them of something and also be respectful of the things they're trying to convince you of and keep an open mind and understand that there are often many right ways to do things or right opportunities.There's not a single answer. **Ellen:* I want you to touch upon the idea the product manager is not the CEO of the product, especially for this interview on product leadership.* **Matthew:** I remember when I was at AT&T, I'd been there for, I don't know, a few months in a product strategy role.I was really excited.I was like, “Oh, I don't have to be responsible for a team or delivery.I'm just going to sit here and make cool PowerPoints and do strategic thinking.” That, of course, didn't last very long. Then they did a big reorg.They were like, “you know that strategy you came up with? Now you have to go implement it.”And they handed me a re-orged team and a bunch of products and stuff. The people I inherited were told by their old boss that they were the CEO of their product.I said, “Well, that's not true.”You don't control sales, you don't control marketing, you don't control engineering.You can't set budgets.You don't have P&L responsibility, which was a thing we were changing in the reorg was to bring P&L responsibility into product.And you can't just tell people what to do. A CEO is a funny job in general. They're ultimately responsible for all these things, and people do report to them, and they have the right to hire and fire people, ultimately, all throughout the organization. They're the only person who can really do that. A product manager can't.You can't think, “Oh this engineering manager is slow, so I'm just going to fire them.”No, you have to go to your engineering leader and be like, “Can we have a chat about Joe and his delivery?**”** You just don't have these rights. You have to approach the job in a totally different way because you don't have that capability.And again, you have to work with your partners. The most successful thing I did at AT&T was because I started with, “This is an interesting product problem to solve.”Then I spent a bunch of time with my channel marketing leader to ask, “How do we sell this thing?And is this a thing we can sell?”We aligned on the pitch.It's what made the product successful.We could have made a cool product and if the sales guys don't care about it or don’t want to sell it or don’t understand it, it will go nowhere. Because this was a sales-force driven company, it was not just self-serving or whatever.I think that was very insightful.You had to think about everyone as your partner, not someone who reports to you. I get really cranky about that because I think it makes product managers really self-important and think they can tell other people what to do, and that's a recipe for failure. **Ellen:* Yeah, it definitely makes it difficult to influence people if you approach it that way. What are three tools you use every day that you would suggest to aspiring PMs to learn, understand or buy? Is there a methodology or software you would suggest?* **Matthew:** The most important thing that PMs have to be able to do is communicate clearly in a written form.There is a visual aspect,like diagramming. Whether you use Whimsical or you could use Figma, or I don't know, I guess you could use something older like Draw IO.We love Whimsical here, for these things. A lot of what goes wrong in product development is miscommunication-based. Being able to communicate really, really clearly both in written form and in basic drawing is really, really important.I think people need to spend a lot of time focusing on that skill. Conversely, product managers should spend a lot of time focusing on listening skills, which is super hard.I've read a bunch of pop psychology books about listening.My favorite one is called You're Not Listening.I love the attitude of it.It's by a reporter. It’s about the psychology of how to elicit information from people and how not to steer conversations.It's a good lesson for life in general, I suppose.It's still very hard to do. Again, it comes back to understanding the problem and understanding how to communicate that problem and potential ways to address that problem.Everything else is just tooling.And I love tooling.I have strong opinions on tools and how to write tickets and whatever else, but that's very functional.If you can't do the primary stuff, then tooling is kind of irrelevant. The most universal skill is essentially communication and listening.Then the writing part, because spoken communication is always hard to follow up on.So even if you have a meeting, product managers have to document it and say, “This is the thing we agreed to and does everyone see this and do they get it and are we all aligned?”Then you can go build things.If you start before that, you're just going to get into a mess. **Ellen:* How do you manage cross functional work and communication across different teams?* **Matthew:** I think, especially in bigger organizations, it's really important to build rhythms that make it easy.For example, an end of development cycle set of demos.We used to do that at Wallaby.Every end-of-sprint, we would have people demo stuff.Sometimes, maybe the BD person would not understand a demo on a command line, which did happen all the time, versus something visual, but it rallied the team into “Here's what we're doing." Another important thing is aligning people on metrics and results, and having shared dashboards. A lot of times, there's this idea that if people have the same information and they're, generally speaking, intelligent and well-meaning, they will come to similar conclusions.A lot of the friction in organizations comes from people using different data.If you give everyone access to the data warehouse and they can just make up their own stuff, they might come to different conclusions.And there's a lot of nuance, right?Like, what is the right denominator for a conversion rate?Is it visitors or is it people who visited a certain page?Right?Or are we talking about performance of an SEO funnel, an SEM funnel, or an organic funnel, or all of it mixed together?So, giving people really clear dashboards is saying, “Hey, we're making decisions based on this set of data and here's how we all access it.”And it's all the same number. Data is messy and people wish it weren’t, and they wish it were totally deterministic.You have to have that understanding.That understanding is important because then it helps align people on the goal and the measurement. It reduces a lot of the arguments. The other big thing is trying to get people to step back from their own individual world and make bigger decisions like once a year.To pick on BankRate, when I got there, prioritization meetings were just a brawl, as they are in many companies.We did this exercise where we got the executive team to agree on around five themes and to allocate resources based on those themes. Then each theme was given a pair of executive sponsors, who were responsible for making decisions largely inside their theme. After that, prioritization got so boring we almost got rid of it because people had this broader responsibility. They went beyond “I'm the marketing person” to “I'm responsible for this theme.”Then we already had decided how resources work.It was no longer “I’m cranky.”Well, some people were probably still cranky, but it was no longer people asking, “Can I have more resources?”Because you know that for this theme, we've allocated 20% of the company and inside that are all these projects and you get to put them in order. People were really forced to make their own decisions within this narrower universe.They can't think, “But can I steal from this other thing?”Because they already agreed that other thing was important and got its 10% of the resources or whatever.So having those big agreements, which are hard, I mean, that took days of an offsite and stuff to get to, reduces a lot of friction and creates a lot of alignment because you already made that decision.Then you can leave the nitty gritty to something less frictional. Where you get really stuck on stuff is when you're arguing every little thing because there isn't that alignment.There are companies that are like that.When I worked at Green Dot, the CEO used to love to pit people against each other in prioritization.He would tell two different people to go argue for their project to be number one.But we would prioritize all 35 projects across everyone, all the time, and move resources around.It was a constant battle. We could have said, we have 35 projects, they fall into these buckets, and we've assigned these resources. That would have been a lot more pleasant, and we probably would have got a lot more done. You lose a lot of time to the thrash of reprioritizing and shifting things. **Ellen:* Absolutely. Where did you learn about that methodology?* **Matthew:** The themes stuff?I sort of made it up, I think.I mean, a lot of these things are from reading a bunch of books and everyone's got a name for stuff. It's sort of like with the OKR-type stuff, where you have these key goals. I don’t use OKRs. I just kind of developed it from trying things and working with people. There's certainly influence from people who have been my coach and books I've read.But again, it's not like a formal methodology, it's just a way of approaching it. It's not something you can do at every company because you need the CEO to buy into the concept, certainly, and make people align on it.You need a place where people are a little bit less selfish, maybe. I describe a lot of things that I've done as versions.When I ran Wallaby, I used to describe what we did as our version of Agile.I'm not a strict methodology follower because I think you need to adapt to the situation.But you can take underlying concepts and use them so that people are familiar with them.Make it work for what you're doing, which changes depending on what you're building, who you're building it with, how big your team is, all those things. **Ellen:* That's really interesting. What is the most rewarding part about being a PM for you?* **Matthew:** I love shipping product.I think it's just so cool to see something that you made out there in the world and people using it. Kind of like with the idea of NPS,which is this question that the McKinsey people invented, which is like, “Would you recommend this?”There are two great measures that tell you if you did a good job: one, would you recommend this; and two, how would you feel if this product didn't exist anymore? That's the thing that was just amazing about Wallaby.We had super-passionate fans of our product and when it went away, people were upset. That was sad, but also very gratifying to know you had built something that really mattered to people and that they were going to miss when it was gone. I'm a little overly enamored with shipping probably, at the expense of other things, but I just love the creativity and the building and the camaraderie of, “Hey, we made a thing.Here it is.”That's just really cool. **Ellen:* Yeah, I love that feeling. What do you think the future of product management looks like and how has it changed since you became a PM?* **Matthew:** Well, it's changed a lot. When I started, almost no one was doing Agile, and most people didn't know what product was.When I went to work at a startup in 2006, post the whole dot com boom, people were like, “That's a terribly dumb idea.Startups don't go anywhere, whatever.”And now startups are so cool. I got this hilarious email yesterday that said Money2020 has grown from a small conference with just fintech fanatics to 20,000 people.I was one of those fintech fanatics because I went the first year. That was very funny. Everything’s more popular.And that really changes the dynamic because you get a lot of people who bring new experiences and new thoughts. There's obviously good and bad to the growth of anything.And then the way we work has changed a lot because of remote work, as you and I have discussed many times. I used to think of product as being very much an in-person/standing at a whiteboard/sitting next to your developer experience.And there are great things about that and there are great things about remote.That's really changed how we communicate.Like Slack is part of everyone's daily life. It did not exist when I started.We used ICQ at Green Dot to instant message across the building. **Ellen:* I don't even know what that is. What is that?* **Matthew:** It's an Israeli instant messaging company that predates AIM and you got a number, so you had to know everyone else's individual number, and exchange the number in real life. **Ellen:* Predates AIM? I don't even remember before AIM.* **Matthew:** I think AIM bought ICQ and then now they're both gone. When I was in college, we all used AIM to communicate with each other.They had this mug where, if you donated to the senior class fund when you graduated, you got a mug and you got to put a word on the mug.I convinced almost everyone in my senior class to put their AIM handle on the mug.That was like how big it was. So, just the way we communicate has changed dramatically.Looking into the future, I think the way we build software is changing because of what we're seeing with AI and tooling, those things really go together.It may be faster to build things, but it may be easier to go astray. I don't think AI is going to take over the world personally and, I don't know, let us all do whatever we want because it'll do everything for us.I think it can be really dumb still. It's probably really far away from being a human.I don't think AI is creative.I think AI is really just regurgitating humanity, which can be useful, but it's a heck of a lot faster to write a little script now or build something out because you can have AI help you.That might really increase the pace at which we can do things, which is exciting. **Ellen:* I like the AI conversation. So, I think this is supposed to go on the top, but what did you study at university?* **Matthew:** Economics. **Ellen:* And how long have you been a PM?* **Matthew:** It's confusing because I've been a CEO in between, but let's go with around 18 years now. **Ellen:* Have you always been a PM?* **Matthew:** Well, kind of. \[Wallaby was\] still a product-led organization. We didn't hire someone to run product until after we sold the company. **Ellen:* What is your favorite book about product?* **Matthew:** I don't know. My favorite business book in general, which maybe is related, is Five Dysfunctions of a Team. Because I think that understanding those interpersonal dynamics are so critical. My favorite book about fintech is the Unauthorized Story of American Express because it's a swashbuckling story of company growth. But yeah, swashbuckling. They all were like shooting each other and stuff. It's wild. 1850s with a different world. **Ellen:* I like to think about Wells Fargo moving money in the horse carriage. That’s all my questions. Thanks, Matthew.* ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # **About ProductFTW** [ProductFTW](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### How to Evaluate an API as a Product Manager - ProductFTW #49 URL: https://www.productftw.com/productftw-49-how-to-evaluate-an-api-as-a-product-manager/ Last updated: 2026-05-10T23:40:36.000Z Throughout my career, I have been asked to evaluate partner APIs or define API requirements for my team. As someone without a deep technical background, I have had to develop a way to determine whether an API will be easy to integrate or a complete headache. There are plenty of product managers who do not work with APIs regularly, and if that is the case, evaluating one can feel overwhelming. You might not have access to technical resources yet or even know how to generate API keys. However, waiting for an engineering team to do the initial evaluation can be a waste of time if the API turns out to be poorly documented, missing key functionality, or fundamentally difficult to work with. Over time, I have developed an approach to evaluating APIs at the earliest stages, before involving an engineering team. If you are a product manager who needs to assess an API without being overly technical, this is how you can do it. ![A cartoon-style illustration of a man sitting at a desk, viewed from behind. He is looking at his computer screen, which displays different colored puzzle pieces fitting together. The perspective clearly shows the back of the man's head, his computer screen, and his organized desk.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-26-15.39.10---A-cartoon-style-illustration-of-a-man-sitting-at-a-desk--viewed-from-behind.-He-is-looking-at-his-computer-screen--which-displays-different-colored-pu.webp) Reading documentation shouldn't be as hard as trying to figure out these puzzle pieces. # 1\. Start with the Documentation An API is only as good as its documentation. No matter how well it functions, if the team behind it cannot clearly communicate what their API does and how to use it, your team will struggle with integration. When evaluating an API, I first read through the documentation as if I were a regular person. I look for clarity, completeness, and structure. If I find myself confused about how the API works just from reading the documentation, that is a huge red flag. Here is what I check for: - **The endpoints are clearly documented.** I should be able to understand what each endpoint does without needing an engineer to explain it. - **Error cases are outlined.** Good APIs provide error messages that help troubleshoot issues instead of just returning generic failures. - **Example requests and responses are included.** If an API does not have examples, your engineers will have to spend time testing and reverse-engineering it. - **Pagination, filtering, and sorting options are explained.** If the API returns a list of results, I want to know if I can control how many I get back at a time or filter them down to what I need. - **Rate limits and usage restrictions are clear.** If the API limits the number of requests that can be made in a given time frame, that needs to be documented upfront. A well-documented API means that the team behind it cares about their product and is making it easier for developers to use. If the documentation is incomplete, vague, or nonexistent, that is an immediate sign that your engineers are going to have to spend a lot of time figuring things out on their own. # 2\. Evaluate Security and Authentication Even without a technical background, there are basic security checks you can look for when reviewing an API. Security is one of those areas that, if overlooked, can lead to serious problems down the line. Some key questions to ask: - Does the API use OAuth, API keys, or some other form of authentication? - How are API keys or access tokens handled? Are they encrypted? Does the documentation mention key rotation? - Are there any IP allow listing or permission settings? Some APIs allow access only from approved IP addresses, which adds an extra layer of security. - Does the API discuss rate limiting and thresholds? If an API allows unlimited requests, that can lead to abuse or performance issues. Good APIs define request limits. If security and authentication are not well-documented, that is a red flag. Even if an API functions well, poor security practices can lead to compliance issues or expose your company to risk. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # 3\. Check for Developer-Friendliness An API should be easy to use, not just for the provider’s team but for the developers integrating it. Even if you are not the one coding, you can evaluate how developer-friendly an API is by looking at a few key factors. A good API should: - Have consistent endpoint naming and structure. If one request is /getUserData and another is /fetch-orders, that inconsistency makes it harder to use. - Use standard HTTP methods properly. GET requests should be used to retrieve data, POST to create, PUT to update, and DELETE to remove records. - Provide meaningful error messages rather than generic 400 Bad Request errors. - Offer sandbox environments for testing so that engineers do not have to use live data just to see how the API works. If an API lacks consistency or requires many custom workarounds, it will add unnecessary complexity to your project. # 4\. Test the API in Postman (Optional but Helpful) If I have access to API keys, I like to test the API myself in Postman. While this is not required for every product manager, it is a useful way to validate whether the API works as expected. The goal here is not to build anything complex but to confirm that: 1. **The API does what the documentation says it does**. If the documentation says a GET request should return a list of transactions, I check that it actually does. 2. **Error handling is clear.** I purposely send bad requests to see if the API provides useful error messages. 3. **Authentication works smoothly.** If getting a valid token or making a basic call is difficult, that is a sign that integration will not be straightforward. You do not have to be technical to copy-paste a request into Postman and see what happens. If an API is well-documented, even a product manager should be able to make a single call successfully. If you cannot, that is a problem. # 5\. Consider the Support and Maintenance Beyond the technical aspects, an API is also a product that needs ongoing support. Some questions to ask: - How often is the API updated? If it has not changed in years, that could mean it is not actively maintained. - Is there an API status page? If the API goes down, is there a place where you can check for updates? - Is support responsive? Some APIs have dedicated support teams, while others rely on community forums. Knowing how you will get help if something breaks is important. APIs that lack support can leave your team scrambling for solutions if something goes wrong. A well-maintained API should have clear versioning, deprecation policies, and a responsive support system. # Why Evaluating an API Matters As a product manager, you do not need to be able to build an API to evaluate one effectively. By looking at documentation, security, developer experience, usability, and support, you can determine whether an API will be easy to work with or a long-term pain point. It does not matter how powerful an API is if it fails in basic documentation or security. If it is confusing to integrate, your engineering team will spend time figuring it out instead of working on more valuable tasks. A well-designed API should be intuitive, secure, well-documented, and easy to test. If it is not, you need to seriously question whether it is the right choice for your product. Making the wrong decision early can lead to delays, frustration, and unnecessary work—and as a product manager, avoiding those pitfalls is part of the job. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Product Talks with Ellen Dearborn - ProductFTW #48 URL: https://www.productftw.com/productftw-48-product-talks-with-ellen-dearborn/ Last updated: 2026-05-22T01:57:26.000Z For our ninth post in the [Product Talks](https://www.productftw.com/product-talks/) series, we’re talking to Ellen Dearborn, Product Principal at [Totavi](https://www.totavi.com/?ref=productftw.com). As you’ll read, Ellen and I had a rocky start to our working relationship, as she was assigned to my team through a disruptive re-organization at Bankrate following their acquisition of Wallaby. We’ve come to be friends and colleagues, and Ellen is a key part of Totavi today. ![](https://www.productftw.com/content/images/2025/05/product-talks-Ellen.png) **Matthew:* What did you study at university and what did you first think you were going to do as a career?* **Ellen:** I studied international business in college, which I'm sure you did not know. When I was going to school, I was convinced I was going to become some kind of economist for another country. At that time, I was really interested in figuring out how money moved across borders. \[laughs\] Wow, I never even made the connection to where I'm at now. But at the time, I was sure I’d end up living abroad, figuring out how to do business with the U.S. from another country. **Matthew:* So how did you end up being a product manager?* **Ellen:** I think the first time I thought that I wanted to be a product manager was when I was working at Bluefin Labs. Basically, the team was creating internal tools for social media listening. I would spend a lot of time with their product managers, giving them feedback, and I thought, “Oh, I could totally do this. I can see problems with tools. I am the user.” I think that was my first glimpse at what it possibly could be. At the time, I just didn't think I was capable. I was right out of school and had no idea what I was doing. So fast forward to when I was working at CreditCards.com, a similar theme emerged where I was using internal tools, and they were terrible. I was constantly giving feedback to the engineering team, and through that, I kind of progressed into being a product manager when we didn’t even have the concept of product management. Then I found my first mentor. \[Editor: This was Matthew.\] He really showed me the light. **Matthew:* How did you end up at CreditCards.com? What was the job you took there?* **Ellen:** I took a job as a product information manager and my job, very similarly to Bluefin Labs, was to take information and then put it into a system. I knew that I was capable of doing that, so I interviewed from thousands of miles away. I just desperately wanted to move to Austin, Texas. It was a lot of data entry. From there I progressed into product ops and then went into product management. **Matthew:* I recall when Kamelia, who was the new CTO, joined, she did an Agile transformation project and through that you got product owner training, right?* **Ellen:** I did. I became a Certified Product Owner. **Matthew:* Oh, no.* **Ellen:** At that time, I had the certificate and everything. **Matthew:* I think this is an interesting aside. Having come into product through that strict Agile scrum methodology and then having had other experiences since, how do you think about the question, “What is a product manager?” Like, what does product management mean to you, and what are some of the key differences when you hear people talk about those roles, like their PM versus their PO?* **Ellen:** I think that this is a pretty frustrating conversation as a product manager because a lot of times you're going to be pigeonholed into a methodology rather than being able to do your job. Actually, prior to the massive Agile transformation, there was this really big push for lean product development. I don't know if you remember this, but we were sent to this lean product development course in the middle of Austin with a bunch of other product people and designers. We came back and had to use the lean product playbook, where they have those pieces of paper where you draw stuff. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:* Was that before or after Kamelia joined?* **Ellen:** I think it's right as she joined, right before we went to Agile. The progression of my career was very much from data entry into leading teams on how to do things. Then really trying to figure out how we build technology rather than just being order-takers. The first stab at that was the lean product development and then the massive Agile transfer transformation. There are themes that you pull from that in your career. I think that you should explore many different concepts of how to “do” product. As a creative thinker, problem solver, and strategist – which most product managers naturally are – you should pull in the approaches that resonate with you and have proven effective, and make them part of your own playbook, rather than sticking rigidly to someone else’s. I know you and I have talked a lot about Agile during the early 2010s. It was kind of like the “Agile Bible” or “Religion of Agile,” where people were just complete cultists. Being so rigid doesn't enable you to have the flexibility to actually build things. You're kind of crippled by the process rather than using it as an effective tool to be able to get your team to commit to timelines and actually build software. **Matthew:* To use one of Kamelia’s favorite sayings, it's one of those things that is a hammer that makes everything look like a nail. People try to throw Agile at everything. We'll come back to this in the opposite interview, but when I was at Green Dot, we had a failed Agile transformation. That was my first Agile experience. A VP of app dev, he came in and tried to do it, failed, he got fired. Organizationally, it's not the right choice for everybody. Certainly, I think in the era when you were coming into product, it was extremely hot. I mean, it's still very prevalent.* **Ellen:** I don't think I've ever seen a “successful” Agile transformation, but I do think it provides a common language and framework for teams to work from. But then some people take it too far and ruin it. At every company I've worked at, I've only seen the ruins and not the actual benefits of it. **Matthew:* So thinking about this early part of your career and product, if someone comes to you today, let's say they're 23, and they say, I'd like to be a product manager. What advice do you give them?* **Ellen:** I would say that they should do as many jobs as they possibly can. I actually recently had this conversation with my mom, where people equate product management or any technology role to a lot of money and want to know how one gets into that. My personal belief is that in order for you to be an effective product manager, you need a lot of practice at solving different problems and experiencing a lot of different pain points, so you can kind of connect it to you. So if I was to give a recommendation to someone who is 23 or Julia \[Ed: Julia Nicholls is Associate Consultant and person-of-all-trades at Totavi\], I would say she's doing actually exactly what she should be doing right now. And although it might not seem like it, and it might seem really grueling, what she's actually doing is feeling the pain point of actual manual labor in the technology world. Just like me starting with putting in information into a system while thinking, “This is super inefficient. How can I solve it?” Then you slowly progress into being able to solve it and then being able articulate those problems into solutions that technology teams can actually go and implement. In order to be a good product manager, you have to experience the pain yourself. It's always easier to start with a problem that is your problem rather than starting with solving someone else's problems because it's hard to build that empathy until you know what pain feels like. **Matthew:* As you mentioned, you don't have a computer science degree. You don't have a technical background in the traditional sense. So how do you think about what makes a good PM and also, for yourself, you’ve become a leader of product managers and you've hired product managers. So how do you think about the need for technical backgrounds – whether it's good, bad, or indifferent – and also how have you developed technical skills over your career?* **Ellen:** If you're not coming from a traditional background, you need to have curiosity and leave your ego at the door. The most successful product managers I know are the most thoughtful when it comes to approaching a problem. I do not have a technological background but I also think I'm tech savvy. I got to this place just by being curious and not letting the fact that I don't know exactly how everything works prevent me from being curious enough to explore it myself. In the past, I've asked supervisors to sponsor me in doing some online courses, which helped. For example, online coding courses for HTML because I just wanted to know more about how websites worked at that time. Or, getting API keys to play with. Just being able to play with tools helps you get an understanding for how they work and ultimately gives you the ability to solve for them later. So although I've never created an API, now I would feel confident in doing so because I've been a user of many APIs, I've evaluated many, and I've also worked with a lot of SDKs. I think just downloading the software onto your computer, whether it's Postman or something else, and playing around with it and understanding the basics, is the best way to get to the technical background that you need as a product manager without physically coding. And I think it's healthy that I don't have that background because I am too authoritative and it's hard for me not to cross into the “how” realm. So if I had more technical skills, I would for sure be arguing with my developers about the best solution. I like to know enough to ask questions, but not so much that I'm telling them how to do their jobs. **Matthew:* When you think about the product managers you've hired and managed in your career, and whether they're technical or not, is there any theme? When you think about who your favorite one is or who were the most productive and successful, do they have technical backgrounds or, if not, what are their backgrounds?* **Ellen:** I'm looking for someone who can speak to all audiences comfortably and confidently. I don't know if I was necessarily looking for something on their resume that would indicate to me that they were technical. I think a good, well-rounded interview process gives them exposure to different people. Thinking through who I am selecting for their interview panels, I want them to feel like they can hold their own conversations without feeling like they're lacking in some way. To answer your actual question: No, I was never looking for a technical background. And the thing that would be on a resume? Oh, well, that's complicated. I don't know if I was looking for one thing on a resume other than: Did you actually take the time to structure your resume well? Did it convey things clearly? Were there spelling errors? And it was less about your ability to do the job and more about did you check a series of boxes in order for me to get in front of you and feel like I could have a conversation with you that would indicate to me that you're a strong communicator? Because the number one thing as a product manager is you need to be able to communicate effectively. And that includes writing, so that would be the resume. **Matthew:* Shifting gears a little. What do you think is one of your biggest challenges as a product manager? And what did you need to solve it? This is the question section where it sounds like you're getting interviewed for a job. Sorry.* **Ellen:** Yeah. I'm just laughing because some of mine are with you. **Matthew:* That's fine. You don't have to hold back.* **Ellen:** Well, to toot my own horn. **Matthew:* As you should!* **Ellen:** In all management scenarios that I've had, I've had a lot of friction with my managers. First, starting off with you. Then moving into Red Ventures. And then even when I moved out of fintech and into cybersecurity, I was actually interviewed for the same role that my manager ultimately ended up having. And so we interviewed each other, and they were pretty much like, are you cool with reporting to this woman because she has more cybersecurity experience than you, but we think you'd make an excellent product leader? I think that the biggest challenge that I've had is being really high performing and always managing my managers to make sure that they're not tightening my leash too much. But do you want me to give an actual story? **Matthew:* Yeah.* **Ellen:** Do you want me to give **the** story, or do you want me to choose a different story? **Matthew:* You can choose whatever story you like.* **Ellen:** I like our story because I think that it shows that all relationships are redeemable. And that just because you're in a really trying situation doesn't mean that it's going to be like that forever and that it can turn into something beautiful. Like, our working relationship now, ten years? Thirteen years later, twelve years later? **Matthew:* This would have been in 2015.* **Ellen:** Okay. Going from product operations into product management, it was basically the wild, wild West. At the time, in the industry, no one really knew what product management was and everyone was trying to figure it out, hence the massive transformations over and over and over again. Because I had worked really hard to be a loud voice at CreditCards.com, when Matthew joined the team and was Head of Product, I wasn't used to having a leader that one, had opinions; two, could actually provide me guidance; and three, was trying to move the company in a particular direction. And so, when Matthew joined, there were too many of us. **Matthew:* Yeah. The essential problem with CreditCards.com was there wasn't a product team. There were some people who had had product owner training. As you did. And actually, the only person with the title of product manager was Vandana. And the CEO created a department out of thin air by transferring a bunch of people around and then seeing if those people could do the work, basically. Because again, Kamelia and her analogies, we were trying to rebuild a car while driving it down the road. Which is really hard. Like, we couldn't stop building stuff to go reset personnel or anything.* *From my perspective, I didn't know anybody. Kamelia had shared her opinions with me, but I was also trying to be fair to people. I mean, I didn’t even know Kamelia that well at that time. I hadn't even interviewed her, which was this whole weird thing. I interviewed a bunch of people for CTO, none of whom took the job. Then they just hired Kamelia without including me in that part of the process, which I always thought was very funny.* *I was trying to give everyone a fair shake by developing my own opinions, which is part of why it took so long for me to make personnel changes.* **Ellen:** I think in addition to those challenges that you're referencing, we also had a bunch of tech leaders who shouldn't have been in the positions that they were in. It felt like a hostile takeover by many of the other software engineers on the team by combining the two offices out of the blue. So there was already a lot of tension going on, and then having a new young guy come in with his own team and people that he favored. \[laughs\] You were a young guy then. It felt very much like an us-versus-them mentality. We felt like we had been doing a good job given the circumstances and the state of the technology and the cultural differences in the office, the deep Southern office. So having someone come in and tell you that you're not doing a good job, that actually everything you've been doing is kind of crap, and that basically things need to change drastically right now was a really tough pill to swallow. I think especially because you weren't in the office, building those side relationships and instead you were coming to visit all the time. We had a lot of time to get together in the coffee room or the kitchen to talk shit, and that built a lot of toxicity within the office. Maybe two months in, there was basically a whole push to get you out of your position and to take back the organization. You're talking about a bunch of 23 to 24 year-olds who feel like The Man's coming on them, and they have really poor leadership with more experienced people who are also hating on you. We're looking to them to help formulate opinions. There is just this undercurrent of “This guy is terrible. He's going to run our business into the ground.” Actually, if we had continued on probably for another year, we would have successfully done that ourselves without you. What ended up happening is Matthew, over video initially, asked us, “What’s going on? I'm hearing grumblings from the leadership team that there’s a problem.” I remember being on video and all of us thinking, “We've been found out, and we're all going to get in trouble.” Because you were our direct manager. Yes, everyone was incredibly unhappy with you, but we weren't ready to tell you. I think the first time you approached it was on video, and we said, “Everything's fine. Everything's great. Everything's fantastic.” You got that Southern hospitality, which is funny because half of us weren't Southern, but you totally felt it. Almost immediately, you came to Austin to visit and basically call people into your office to figure out what the problem was and how you could improve. I remember just being so stressed about it because I'm always the one that wants to give people the benefit of the doubt. Even now, my sister and I were just talking about this. If someone cuts me off, if someone hit me in traffic and ran, I would think, “Oh, they must be really busy.” I always give someone the benefit of the doubt. In that moment, when you were coming around asking people, I thought, “Well, he deserves to know because how are we going to solve any of this if he doesn't know.” Pushing someone out without giving them an opportunity to fix things. I'm not really good with that, even though everybody else on the team was. In my mind, if you don't tell him, he's not going to know, and he can't get better. Since this is my perspective of a really challenging situation and product leadership, I decided in that moment not to be a sheep. That you deserved to know what was going on, and then you could do with that information what you will. I think it was around 5PM, I went into your office, and laid it out for you. And I blacked out. I have no idea what I said, but I was probably pretty harsh. Do you remember what I said? **Matthew:* Oh, yeah. So my memory of this is that I came in and had everyone come into a conference room. I said something to the effect of, “I understand that everyone's unhappy. But you all won't tell me what you're unhappy about or tell me directly. You just go complain to everybody else. I can't fix problems that I don't understand. I'd appreciate it if everyone would stop lying to my face. Because that's what you're doing. I say, ‘Wow's it going?' And you say, fine, but the reality is it's not fine."* *To your credit, you're the only person who came and told me what you actually thought. I mean, you did call me an asshole.* **Ellen:** Did I? **Matthew:* Yeah.* **Ellen:** I can't say that I'm surprised, but I was so scared. **Matthew:* It was fine. I mean, it wasn't a pleasant experience.* *Hopefully, I thanked you. I think I did, because I think the only way to solve problems is to understand them. And then I knew that you were someone I could actually work with, whereas some of those other people, who I later moved out of the organization, were not people I could work with. I understood then that you actually cared about the business and about yourself and your job and weren't just playing the political games. I could have helped any of those people with the right attitude to become great product managers.* *The other thing about that situation, for which I give credit to Scott Grimes, was when we were doing the reorg, he said that the real problem was I was so worried about how the people in LA were going to feel about being subsumed into a greater corporation. He said, “No. You're backwards. The people in Austin are the ones who are going to be really upset.” Because everyone thought that I had engineered a takeover.* *Actually, Kamelia started the whole thing, insisting that she can't build technology without a product team and asking, “Why do you have this team of people in Pasadena who we can't interface with?” They actually could not have made me do this. I had a contractual term that said that if they changed my job from when they bought the company, that I could have quit and demanded they pay me out all my severance. That was years worth of salary for doing this so early.* *But I always had success in my career by saying yes to challenging situations. I thought, I guess I'm going to do this thing instead of being a pain in the ass. I really regretted it for quite a while, though. \[laughs\]* **Ellen:** Yeah. I'm sure you did. Especially if you have a 24-year old calling you an asshole to your face, but that seems very on brand for me. But you did thank me. And then we ended up going to dinner with Nathan. **Matthew:* I remember the funny in-between thing: Nathan was coming out to Austin for the first time and we met at the hotel to walk down to that whole strip of restaurants. Nathan had worked for me previously. I had known him for a while. I told him, “It's so bad. Everyone here fucking hates me.” He said, “That can't be true.” I'm like, “No. Literally just got told how much they hate me. Like, it just happened. It’s really bad here.” I was trying to set it up because I didn’t know how you all were going to react to him. He’s a new guy from LA we had just hired. We're walking down the street, and we run into you and Jeremy. Right?* **Ellen:** Yep. Which is hilarious because Jeremy and I went to dinner to debrief on the fact that I told you that you were an asshole. Then we all ended up having dinner together, and that's honestly the only reason why I'm here today. I was like, “Man, if some guy can take that kind of verbal abuse and then go to dinner, that’s someone I want to know and trust.” And so here we are, eleven years later. So I would say that's probably my biggest challenge and a theme that's been a challenge in my career. I think when you're high performing, it's hard to have someone tell you what to do. And you've always been really great at not really telling me what to do unless you needed it. You just say, “Figure it out.” Great. I will. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:* Let’s move on to less emotional topics.* *Thinking back to the people early in their career, what are some of the tools or things that you think people should learn so that they can grow their career? This could be literal tools like software or it could be books or it could be newsletters. Whatever.* **Ellen:** As a product manager, I would say the number one thing that you should start with is how to write a user story. I think that is kind of a microcosm for everything else you're going to do. You need to be able to briefly and succinctly describe a problem and the outcome that you need, including the what, how, and why, in every different aspect of your job. If you can do that really well on the smallest part of the work, then you can do it at scale. I would say learning what a user story is, you can find it all over the Internet. Doing it well is the hardest part. And then once you unlock it, you're able to kind of make that story into being able to send an email, being able to get into a boardroom and give a presentation. It is the smallest place to start and, I think, the easiest place to start. But it is the most difficult to master. Then I can give a bunch of different books and stuff that I found interesting, but I don't think that reading them and making your own style is the best way to do it. I think all product books are beneficial if you walk away with a little tidbit here, a little tidbit there. That helps you, but every job is going to be different. **Matthew:* What is the most rewarding part of being a product manager for you? You could also answer this with something you shipped that you're really proud of.* **Ellen:** I actually think it's rare as a product manager to ship a bunch of stuff, like a whole product. Usually, it's pieces that do something cool. And sure, I have those stories. But I think the most rewarding part of product management is helping people. Your business coach and I met once to discuss you, but then he also analyzed me because he can't help himself. He asked me, “What's your one driver?” You know how he did those Venn diagrams of your work and your personal life? One of the things that came out of that is that I have this strong desire to help people, and it doesn't matter what I'm doing as long as I feel that people are going to benefit from it. At that time, especially with your coach, I always thought that I was going to go into something philanthropic. I have looked at jobs there, but the problem is they're almost too real for me, and I'm too empathetic. The emotional tax that I would pay is too high. So the thing that I love about product management is that I get to help people on my own terms - help them solve problems, help them make their life more efficient. That's my main driver. So if I don't see the value in it, if I don't feel like we're solving a problem that's going to help people, then it is really hard for me to actually apply myself to do that. **Matthew:* You've been in product for over a decade now. What are some of the key things that you think have changed over the past ten years, and how do you think it's going to change over the next ten years?* **Ellen:** I actually don't think that there has been a lot of evolution in product management over the last ten years. **Matthew:* Spicy. Hot take.* **Ellen:** \[laughs\] Hot take. I think there's been a common theme of wanting to define what product management is and a really big push that everyone needs it. But as far as the role, I don't think the role has changed. People have always needed someone to come in, be able to articulate problems, and then help guide them in how to solve them. That always hasn't always had the product management title. When I first got into product management, I don't think that people knew what it was and that, at the time, it was a really hot topic. Everyone wanted to do it. It made a lot of money, but no one had any idea what they were supposed to do or what it looked like. Over time, there's been many different variations on how to define that. But I feel like every time there's been a really big spike in trying to determine what it should be, we are actually defining it in a way that takes it away from its core, which is solving problems for people. Instead, we need to make the role more important. Product managers need to make a big push to be a CEO of the company as was the trend five years ago and people need to be reminded that product managers *aren't* project managers, though at the core, they kind of are, as well. Every time the field has tried to evolve over the last ten years, it's always been evolving in making the role more than it truly is and adding on more responsibilities. Otherwise, I don't think that it's changed that much. **Matthew:* Do you think it will change in the next ten years?* **Ellen:** I do. I think right now, we're in the stage where it's actually just about to start vastly changing. The addition of AI, in some ways, makes our job even more important. I know that people are really scared about AI coming in, but AI is not truly artificial intelligence. It still requires a human. As things are more automated, having a voice of reason, a voice of the user, and someone who can analyze the outputs and actually take whatever those outputs are and put them into an actual solution, is going to be more important than ever. I think that the product manager role will evolve with AI to be closely tied together, where it helps product managers do their job more efficiently. Also, we are going to be more focused on data than we ever have been. Over the last ten years, we've always wanted to be hyper-focused on data, but it hasn't been as easy. Now data is going to be so easily accessible, we're going to be able to iterate much quicker. **Matthew:* Alright. Thanks for chatting with me today!* # **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### What Makes a Good Flow Diagram? - ProductFTW #47 URL: https://www.productftw.com/productftw-47-what-makes-a-good-flow-diagram/ Last updated: 2026-10-14T01:25:33.000Z As a product manager, I am constantly asked to create flow diagrams or review diagrams from partners. Over time, I have developed a strong sense of what makes a good flow diagram and what makes one confusing and difficult to follow. While I would not go as far as calling myself an expert, I have worked with enough flow diagrams to know what works and what does not. The whole purpose of a flow diagram is to visually convey a sequence of steps in a way that is easy to understand at a glance. If a flowchart requires too much text to explain itself, it is not doing its job well. A good flow diagram should be clear enough that someone unfamiliar with the process can understand it without needing extensive explanations. When I create flow diagrams, I follow a few principles to make sure they are readable, logical, and structured in a way that minimizes confusion. ![A side-by-side comparison of two images. On the left, a chaotic spread of cooked spaghetti and meatballs arranged on a countertop, with strands of pasta looping in various directions and sauce scattered throughout. On the right, a clean and colorful flowchart composed of geometric shapes (rectangles, diamonds, circles) in blue, green, red, and yellow, connected by black arrows, all against a light background.](https://www.productftw.com/content/images/2025/04/CFTW--1-.png) Which one would you rather try to figure out? # Readability Without Words The best flow diagrams do not rely heavily on words. If the diagram needs large blocks of text to explain what is happening, it defeats the purpose of having a visual representation of a process. I use Whimsical as my preferred tool, and one of the first things I consider when creating a diagram is character constraints within a box. In Whimsical, you can fit about 32 characters before a box expands, and I try to stay within that limit. Keeping the text short forces clarity and prevents over-explaining. If the diagram needs extra context, it should be supplemented by notes outside the flowchart itself, not crammed into individual boxes. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Match How People Read In North America and most Western countries, people read left to right and top to bottom. A good flow diagram should follow that same natural reading pattern. - The starting point should be at the top left of the diagram. - Steps should flow downward and to the right, following a logical progression. - The final outcome should be at the bottom or rightmost side of the diagram. I do not use step numbers because numbering takes up space and is unnecessary if the flow is structured correctly. The flow should be obvious without needing to count steps. # Swim Lanes to Define Responsibilities A messy flow diagram is one where it is unclear who is responsible for what. This is where swim lanes become critical. Swim lanes help separate different parties, tools, or processes so it is immediately clear where each step belongs. For example: - If multiple teams or systems are involved, each gets its own swim lane. - If the flow involves a partner, an internal team, and a customer, swim lanes keep their actions separate. - If there is a handoff between systems or teams, the transition should be clearly marked with connectors. Without swim lanes, flow diagrams become harder to read and interpret, especially when dealing with multiple stakeholders. # Minimize Crossing Lines One of my biggest pet peeves in flow diagrams is unnecessary line crossings. A diagram should be structured so that lines do not overlap or intersect whenever possible. Confusing diagrams usually: - Have lines crisscrossing everywhere, making it hard to follow the path. - Do not take the time to reorganize elements for better clarity. A good diagram takes the time to optimize the layout so that: - Lines flow smoothly from one step to another. - Decisions and branches are clearly separated. - There are minimal back-and-forth jumps. If a flowchart looks like a spaghetti mess of tangled lines, it needs restructuring. 99% of the time, with a little effort, you can rearrange boxes to avoid crossing lines entirely. # Keep It As Simple As Possible A flow diagram should not try to capture every single edge case in a process. Its job is to show the core flow and help people understand the big picture. One of the best ways to keep a diagram simple is to break it up into logical sections. Instead of trying to force everything into a single diagram, consider splitting it into smaller flows. **Happy Path vs. Unhappy Path** A clean way to structure flow diagrams is by separating the happy path from the unhappy path. - The **happy path** should show the ideal user journey when everything goes right. - The **unhappy path** should focus on edge cases, failures, and error handling. This separation ensures that people reviewing the diagram can clearly see how success works before diving into failure cases. It also keeps diagrams less cluttered. **Breaking Down Large Processes** - If a process has multiple phases, break it into multiple diagrams instead of cramming everything into one. - Use high-level flow diagrams for an overview and detailed sub-diagrams for more complex interactions. **Grouping Related Actions Together** - Similar steps should be visually clustered rather than spread all over the place. - This makes it easier to scan the flow and understand how different actions relate to each other. A complex diagram that tries to fit everything into one place is harder to maintain, update, and understand. Simpler is always better. # A Flow Diagram Should Work Without Explanation A well-designed flow diagram should not require someone to explain every part. It should be clear just by looking at it. Next time you're working on a flow diagram, follow these key pointers to ensure you make it great: - Use as few words as possible. - Follow natural reading patterns from left to right and top to bottom. - Use swim lanes to make responsibilities clear. - Minimize crossed lines for better readability. - Keep it simple and only show what is necessary. Taking the time to clean up and structure a flow diagram properly can save teams hours of unnecessary confusion and miscommunication. A bad diagram leaves people with more questions than answers, while a good one makes complex processes easy to understand at a glance. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Building User Authentication - ProductFTW #46 URL: https://www.productftw.com/productftw-46-building-user-authentication/ Last updated: 2026-06-04T19:27:23.000Z Most user experiences today start the same way: login. Outside of a few *truly* read-only corners of the internet, nearly every product assumes a logged-in user. This means that when you’re building something new, the first real feature you build — whether you realize it or not — is authentication. That wasn’t always the case. Early websites were wide open. You just showed up and read what was there. Take my own site, for example. Here’s an [awkward version](https://web.archive.org/web/19970109153508/http://www.layouth.org/ruler.html) of it from 1997 via the Internet Archive. No login, no tracking, no cookies, just teenage me oversharing on the internet. ![Teenage boy in jeans and a sport coat standing outside in front of a black 1968 Mustang fastback](https://www.productftw.com/content/images/2025/04/young-matthew.jpg) Young Matthew Goldman and his beloved Mustang Fast forward to today: my personal site,[ matthewgoldman.com](https://matthewgoldman.com/?ref=productftw.com), runs on Ghost, the same platform powering this newsletter. It’s still mostly static (90% of its traffic is about spoonerisms, weirdly enough), but guess what? You can log in! There’s a full backend with user roles, an admin interface, and role-based access control. Even when you don’t *need* auth, it’s lurking in the background, quietly powering the modern web. It’s not just me. Early versions of major publications like *The New York Times* didn’t require login either. But as soon as content personalization, saved preferences, and subscription models entered the picture authentication became table stakes. This evolution became really clear to me in 2014 when Bankrate, Inc. acquired my startup, Wallaby Financial. At the time, none of Bankrate’s websites allowed consumers to log in or manage data. No personalization, no dashboards, nothing. Wallaby’s biggest strategic asset wasn’t just credit card recommendations: it was a full user-authenticated experience with custom data and personalization. That was a big deal. ![Diagram of how to run authorization in black shapes with lines and arrows between them.](https://www.productftw.com/content/images/2025/04/Screenshot-2025-04-30-at-1.50.17-PM.png) This classic auth flow should make the decision for you When we started Wallaby in 2012, there were libraries to help you build authentication, but no real services. You had to roll your own. We used a Java OAuth library, and it was *miserable*. Auth is one of those features that seems simple on the surface, almost boring, even. It’s required in nearly every app. It’s conceptually well understood. And yet it *always* causes problems. Worse, nobody wants to own it. Auth lives in this awkward space: critical to your product but rarely a core differentiator. It’s too risky to ignore and too annoying to prioritize. Today, we’re lucky to have services like[ Stytch](https://stytch.com/?ref=productftw.com), Auth0 (now part of Okta), and built-in options from cloud providers. In theory, you can just plug one in and move on. But in practice? There’s *always* some weird edge case that the service doesn’t support. Do you want to add a secondary email? Tweak session expiration? Auto-logout after 15 minutes of inactivity? Suddenly you’re writing custom code again. Back to engineering, it goes. I’ve yet to work with a team that *wants* to outsource auth. Everyone thinks it’ll be easier to build it themselves, but most of them regret it. Teams burn weeks (sometimes *months*) trying to get it “just right,” only to end up with bugs, brittle logic, and poor UX. When you’re early—pre-product/market fit, pre-scale—your job is to move fast and focus on your product's real differentiators. Authentication probably isn’t one of them. My advice? Use a service. Make it someone else’s problem. Save your energy for the things that actually move the needle. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Product Talks with Zach Bartholomew - ProductFTW #45 URL: https://www.productftw.com/productftw-45-product-talks-with-zach-bartholomew/ Last updated: 2026-05-22T01:57:25.000Z For our eighth post in the[ Product Talks](https://www.productftw.com/product-talks/) series, we’re featuring Zach Bartholomew, VP of Product at [perigon°](https://perigon.io/?ref=productftw.com). Zach and I met when he applied for a product manager role at Bankrate in 2016\. Our slow process had us almost miss hiring him, but we managed to make it work and I am so grateful we did. Since then, Zach has been a Founder and a Head of Product. He is also a [regular contributor](https://www.productftw.com/author/zach/) to ProductFTW. ![Promotional graphic for Product/FTW’s 'Product Talks' featuring photos of Matthew Goldman and Zach Bartholomew against a gradient background. The tagline reads, 'It’s like a podcast, but you have to read it.'](https://www.productftw.com/content/images/2025/04/Zach-Bartholomew-1.png) Product Talks with Zach! **Matthew:* Hey, Zach. How are you doing? I know this already, but since we're doing an interview: who are you, what's your current job, and what does your company do?* **Zach:** I'm Zach Bartholomew. I'm the VP of Product at perigon, which is a startup that focuses on news aggregation right now. We have a big, different new app coming soon, but we'll see when this is published and if it's out by then or not. \[Note: It is! Check it out\] **Matthew:* Tell us about your career path. What did you study at university, and then how did you get into product?* **Zach:** I got my computer science degree, and right out of college, I was a software engineer at AT&T for a little over four years. While there, I worked on a lot of Java backend middleware code and learned very quickly that I didn't like being that deep in the code. I like being technical, but just writing code all day, every day was not satisfying or gratifying. So, very quickly, I found myself searching for different roles. At the time, product wasn't really a role. I didn't even know what it was. However, I started working on a new team at AT&T that was, in part, responsible for managing a lot of estimates that some of our consulting or contractor vendors would send. We would get thousands of emails a month that would have an Excel attachment with estimates and quotes for a given piece of work. My team was supposed to take those, open the attachments, copy the cells, and paste them into a shared spreadsheet. I thought that seemed dumb, so I created this little application that parsed the email, had a database, and had a UI that allowed us to start tracking vendor management quotes. Very quickly, other teams were interested in this concept, so I ended up pitching it to our leadership team. They gave me a little money, like $300,000, to staff a team and build this application properly so it wasn't running on my desktop anymore. That was my first introduction to product as a discipline, and I was the product lead. We built that app in about six months, and that was the kickoff to a career in product. I’ve had product roles ever since. **Matthew:* What was your first role where you were called the product manager? What was different about that from your AT&T experience?* **Zach:** My first official role was more of an Agile role in a payments company. I think the official title was “Product Owner/Scrum Master.” It was very early in the days of Agile transformation, and that company was hot on that. I think realistically, I was probably more scrum master for the first few months, while I didn't know shit about the products or payments. It was a little bit trial-by-fire because very quickly, I had to actually figure out how all this works, how I can make it better, and who my customers are—all of the classic product things. I think I was a little bit, I don't want to say over my skis, but I definitely learned a whole lot that I didn't even know I needed to know. This was specifically for business intelligence and data warehousing. It definitely had a technical component which I was able to lean into a lot more than the payments aspect of it, which was definitely helpful. Then from there, I had a gap and took some time to work on other things. **Matthew:* What brought you back to product?* **Zach:** I got back into proper product management at a larger company, creditcards.com/Bankrate. I think what caught my eye was it was definitely still financially related. I did like working at the payment company, but I did want to have something a little more startup. I think what you ultimately pitched me on was, we feel like a startup with money. I thought, “Awesome. That sounds really appealing.” **Matthew:* Was it true? Did it feel like you were at a start up with money?* **Zachary:** (laughing)No. No, not really **Matthew:* I can't believe I said that to you. I was in sales mode.* **Zach:** It was mostly a good time. I was at creditcards.com for a few years and got to work on a big consumer facing consumer branded site, whereas historically my experience up to that point had been very enterprise focused or B2B. I got to experience thinking about SEO and how to optimize for that. Ponder what does it mean to run campaigns and measure campaigns of not only SEO but SEM and other aspects. These are maybe more product marketing, but still makes you much more of a well-rounded product person. Things like optimization, funnels, and all that good stuff. Worked with The Points Guy for about two and a half, three years, where we built a mobile app. I just continued to flesh out the missing parts of what it means to build and run software products. I've had mobile, I've had front end, back end, B2B, and consumer experiences. With that, as I started getting titles that were more leadership focused, I definitely had the experience that I could lean into and say, “I've done this” where I felt much more competent for just about anything that could be thrown my way. That ultimately landed me where I am today at perigon as Head of Product. Right now, we are just the API platform, which is very technical, and also leaning into the AI space, which I'm learning with everybody else right now. We're building a front end application, so I'm able to lean into my technical background and all of these other product-related things that you need to take a product from zero to one and one to hopefully millions. **Matthew:* After all those varied experiences, what does product management mean to you, or how do you explain it?* **Zach:** Man, there's so many ways to describe it. Ultimately, the product manager is solving a problem that a customer has. That’s how I would describe it to a layman. What it realistically means is that if you're a good product manager, you're the linchpin; you're the person holding everything together and making sure everybody's aligned. There are aspects of project management, but also knowing the customer and what the customer cares about, knowing your product and how the product works both technically and from a business perspective, and all the levers that you can use to make better products that ultimately your customer wants and will pay for. **Matthew:* If someone comes to you and is maybe switching careers or is earlier in their career and asks, “What’s your advice for me to get into product?” Or “How can I be a good product manager when I start?” What do you tell them?* **Zach:** I’ll give an analogy. Steven Trong came to me and asked that back in prod-ops days, and what I told him was, “Steven, you are the most knowledgeable person about this specific product in the entire company. And there are things that only you know how they work and how they impact the rest of the business. So, already, you have subject matter expertise, which is a critical competency of any product manager. I think you can take that and start to act like a product manager and say, ‘We need to build XYZ to ultimately bring more customer and user value to the overall platform. You can use that as a launching point to get into product.’ And he got into product and now is an amazing product manager, eight years later. It's finding a big company, finding a project or a product that you can ultimately lead and then propel yourself into that more product role. That's all caveated by whether that organization supports products as a discipline, which many do not. **Matthew:* Indeed. Do you have any books, blogs, newsletters, or other resources you recommend people read or do to learn more?* **Zach:** Yes,I actually have a few. I think the tried-and-true “Lean Startup” is a good one. Marty Cagan's books are a good foundation. I think the common refrain is they're not super realistic, which I tend to agree with. There's a newer book that I think is just a PDF, but it's literally called [“The Product Book.”](https://productschool.com/resources/ebooks/the-product-book?ref=productftw.com) I feel like it does a good job of balancing things that Marty Cagan talks about, and it weighs them up or matches them up. “Okay, but in the real world, it looks like this.” That's what I would recommend to a lot of people. I think another one, more for PMs that are working on maybe front-end or consumer applications, is “The Design of Everyday Things.” The Norman book. Another classic that makes you just look at the world differently **Matthew:* What was one of the biggest challenges you had as a PM, and how did you leverage those product skills to ship the thing or solve the problem, or whatever the case is?* **Zach:** Let me think here. I thought it was going to be where you lost the battle. I was thinking, “Oh, when we built that freaking CMS piece of sh\*t as opposed to buying our own.” Anyway, not that one. Do you remember that? **Matthew:* Yeah.* **Zach:** Hmm. Maybe I can talk about my current role. We are a post-revenue startup. I mean, we are a seed stage, but we are a multi-million-dollar business that was built with simply an API platform. We continued to get feedback and feel this pull towards expanding beyond just a developer product. With that, we started to go out and test the waters of what it would look like to build something. Maybe not consumer, because developers ultimately aren't consumers, but what is pulling us? Why do we feel this pull? Leaning into those product skills, we talk to current customers and people who might fit a profile of customers we want to have and really start to see what problems we think we can solve with an application rather than an API. Over the course of, let's call it the last eight months, we've gone from simply an idea to almost a full-fledged product that will be live in about a month. We've gone with the classic: we talk to customers, we show them something, we get feedback, and then we iterate on that. So we've continued to do that for many months. Now, we have many more months to iterate upon it. Those core product skills, I think, will help to get from zero to one. Hopefully faster, but without feeling like you're just maybe chasing your tail or just kind of winging it. We feel like we had a foundation that we could lean upon that I helped guide us through and ultimately launch a very successful product. **Matthew:* You're in an interesting spot, right? You're the first product hire at a company, and you're the Head of Product. Do you have anyone on the team yet?Do you have any other PM's?* **Zach:** Yeah,we have one PMright now. And then we have designers andthe other product support roles. **Matthew:* This is the thing I spend a lot of time pondering in many different situations: Being the head of product at a startup where you have a founder running the company and the founder is the visionary. How do you think of the role of head of product in terms of vision and roadmap when you're in that kind of situation versus if you were at a big company and a CFO is running the place?* **Zach:** Yeah. Balancing that is walking a tightrope because they started the company and they have the vision. I think it's being the enabler of that vision. In my specific example, Josh is quite technical, but there's a level of technical things he doesn't care about and doesn’t matter to him. And then there's also me being the sounding board. So, both empowering him and collaborating on a vision has been what we've been doing here, but it's also pushing back on things that may not make sense, not necessarily in support of the vision, but in support of shipping products. There are many times when any CEO will say, "We should go do that shiny thing over there." It's one of my core responsibilities to make sure that we're pointed in the right direction and focused on the things that matter the most. In my unique situation, where we have a strong, very successful CEO and me as kind of his counterpoint, we can balance each other out. He has strengths that I don't, and vice versa. And I think we have a good partnership where we're both pointed in the same direction, but he's more long-term, and I'm more in the short to medium-term. Maybe that's a good way to think about it. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:* One of the other things I think a lot about with product is our process orientation and building the pipeline for shipping. How do you think about, given your range of experiences – at startups and at zero to one companies, you've worked in series B, you've worked in giant corporations – how do you think about tuning the level of process and the approach that you bring and, using your current company, how are you deciding how much process or how little process? Can you talk to us a little bit about how you guys work? What is the method? Is it Agile? Is it something completely random? Is it just the Zach method? What are you actually doing?* **Zach:** I would say we've tried a couple of things, specifically about Perigon. We've tried a few different things. The current team has done Agile in some form or fashion for a good long while. I think we're all pretty competent and experienced in traditional Scrum/Kanban, so we wanted to try something a little different. We tried one-week cycles, which were more Scrum/\[Kan\]ban. We would do typical planning and talk about what's on deck. We would not do grooming because we would have one-week cycles. We would do grooming and planning all in one go. That was interesting and kind of worked when the team was very small. When we had three or four developers, that worked fine. As we've grown to double that and beyond, it simply does not work. The amount of planning that the product team has to do just isn't possible in that one week kind of sprint. Nor is it realistic as we start to build bigger things. Is it realistic for an engineer to build a relatively complex feature in one week? I think at certain stages, you start to reflect: This is slow, or this is just not ideal for our current scenario. So, as we reflect, we can say, “This doesn't feel right; this doesn't feel like it's optimized anymore.” We followed that one-week cadence for about a year—up until we were about seven or eight engineers. Now, we're moving back towards the more standard two-week Scrum planning. So we do grooming, planning, things like that. And that works ‘til it doesn't. I don't know at what point it doesn't. That’s what I've been using for a long, long time. **Matthew:* What tools are you using? Whether it's tickets or wiki or whatever. I'm asking everyone this because I'm so curious about tool choices.* **Zach:** We use Linear and Notion. Our process right now is road mapping in Notion. Everything starts with a kind of business case or a one-pager. It's the who, what, when, where, and why that helps us get a sense of the foundational things. Once we decide that this is a project we should actually go and do based on a number of factors, the product manager will create a PRD, and then that PRD will kick off a tech spec. Once the tech spec is done, we then review it as a larger group and then tactically break things into tickets and tasks. This is another thing we experimented with: having the engineers break the PRD into tickets. That did not work at all. I think it can work if you have a product-minded engineering lead or engineering manager who can help balance some of that. But we did not, so it didn't work at all. Now, we're back to products as a result of the tech spec and PRD. Product then creates smaller component-sized tickets that we then put into the sprint work. Linear is used for all of that. Notion is simply core documentation. PRD, tech spec, and everything else that's tactical is in Linear. **Matthew:* How do you do sizing?* **Zach:** We do sizing at a project level. So t-shirt sizes, we kind of say small to extra-large. Small is around a week. Extra large is eight-plus weeks. And if it's that big, we should break it down even smaller. We don't size tickets right now. So that's interesting, maybe? I don’t want to say controversial. But we don't size. Especially at this point, when we're about to ship a product, we are very much Kanban style. Historically, we didn't size either. We just said, “How do we feel like this looks for the week or the two weeks?” Again, because we're so small and just scrappy, I think we would, most of the time, get it all done. But we will have to start to figure out what sizing looks like at a more tactical level. **Matthew:* How frequently do you release, or do you do continuous?* **Zach:** We do continuous. We release just literally any day of the week. Hasn't bit us in the butt yet. **Matthew:* Imean, if you have the right pipeline, you can do continuous. I think that's okay.* **Zach:** Yeah, I think this has been a positive experience from that perspective because, like I said, we push all day, every day, and haven't really run into issues. **Matthew:* I think one of the interesting things about product, as we're exploring in this series, is that there are so many ways that you can do it, and it's very situational. In fintech, in particular. This is interesting.* *There's a podcast series that was being done by one of the industry-analyst types, and he talked to Ramp and Brex, which are effectively the same core product. It's a corporate spend card. Ramp has continuous delivery, and Brex does three releases a year or maybe four. It's super fascinating that they operate totally differently, even though I think they're relatively similarly sized companies. Brex is probably larger and has more complexity to it, but it's a reflection of the CEO and Head of Product’s decisions.* *They have really different ways of how they approach software decisions and releases, and they're both valid. Right? There's no correct answer. There's only the right answer for you. So don't size. Do size. Continuous. I don't care. Whatever works. That's my opinion.* **Zach:** Yeah, agreed. **Matthew:* You guys are pretty small, so you can also think about other experiences at large companies. How do you think about managing communication outside of product and engineering and managing alignment to other parts of the business?* **Zach:** I would say that’s, at least at perigon, it's definitely an opportunity we have because we are small. We simply use Slack for just about everything. We're not super formal with internal release notes or anything like that, which has caused confusion for sure. Communicating to our customers is another area that we need to improve upon. However, there are maybe two ways I think about this. There's the feedback loop from customers that is, I think, a little bit different. I have a core set of customers that I can reach out to and talk about ideas we have or testing things that they'll give us real feedback on. They're kind of our biggest fans, which is nice. Feels like a safe place. On the other side, there's all the other customers where we kind of say, "We've done a product release and we want you to know about it." We have a couple of different ways we think about that. There's the basic change log that we have that gets updated with every release. We also have a team that is kind of an offshoot of marketing, but we have a developer advocate who creates videos on our behalf. He really tries to tap into the developer community. He creates demos and trials to show what's possible, not only with the product, but with the newest release. So we post this on YouTube, and we have a Discord. We're trying to keep an open line of communication with our developer customers in the places where they hang out. **Matthew:* What do you think is the most rewarding part of being a product manager for you?* **Zach:** This is a big answer, but I think going from zero to one has always been the most fun part for me. It's like you have an idea, and then it's an actual thing that people are using, and they like it or hate it – either way. It came to life, and you are now hopefully making money and all those fun things. Zero to one, idea to product, is kind of where I think I get the most satisfaction. **Matthew:* Looking back, what's the product that you've already built and shipped - so you can't use the thing you're about to ship - that you're most proud of? Could be an internal thing, an external thing. Something where you look back, you think, “That was such a great experience. I shipped something really amazing.”* **Zach:** I would say the initial version of The Points Guy app was amazing. It was very well thought out. It was inspired by Wallaby. There were definitely things we didn't do, but we leaned harder into the redemption part of the points ecosystem. I think we built a lot of cool stuff. I left before it really saw the light of day, but I was really proud of what we built. There were so many great things that we had in that first release that have been unfortunately gutted ever since, but I was really happy with the product. **Matthew:* That's good. I mean, that's one of those things. Some of the things I'm most proud of that we've done are very internal. Of the things that we've done together, one of the things that I love that you did was the publishing tool at Cards.* **Zach:** Oh, yeah. **Matthew:* What was that called? Viewbook.* **Zach:** Viewbook, yeah. **Matthew:* Viewbook was a project that the external consumer knew nothing about, but transformed the way the business was run internally and solved a massive amount of problems that we had no solution to at the time. I love those projects because you have a very clear need, you can solve it, and you guys solved it in a really intelligent way. It was transformational, and it made the business better and more reliable, and it had all these other things. It wasn't like, “Gee, I hope customers click on the blue button that I just built.” The core thing we did got at least an order of magnitude better as a result. I always think those are really amazing things. I love the nerdiness of product when you're like, “Ifixed a thing that no one was aware of.” I mean, you don't have to be most proud of that, but I always thought that was an example we would use.* *We were talking about our teams at Bankrate, and that was a huge thing we did because, as you know, when we all got there, we could barely keep the site running. It was delivering $400 million a year in revenue, and it didn't work very well.* **Zach:** That's a good one. I need to remember that in the future when I’m doing this again. **Matthew:* My last question is a two-parter: What do you think the future of product is, and how do you think it's already changed since you got into the industry?* **Zach:** I feel like this is in large part true, but for a while I thought that if you had the right attitude, you were smart enough and driven, you could be a product manager. I think, in large part, that's still true, but my recent experience is I think product people are going to be more specialized. I feel like we're getting to the point where lots of companies are no longer hiring product managers, or they’re changing what a product manager means. And I didn't understand that for a while, but I definitely do now. I think that going forward, product managers are going to need to have a certain expertise. We know that subject matter experts are something that product managers are often, but I think it's probably going to go a step further. I don't think you can just drop into a company and be a great product manager just on your past laurels. I'm trying to think of an analogy without throwing people under the bus. From what little I know about Totavi, you clearly have subject matter expertise in finance, payments, and fintech. So you guys are amazing product people in that space. I don't feel like there's a general-purpose product manager role out there for too long. I think you need to be specialized. **Matthew:* I think that's really interesting because we talk about this a lot. Is there that subject matter expertise required and what is it that we \[at Totavi\] do? So I think that's a really interesting point. Thanks for chatting with me today.* ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Why Great Support Creates Loyal Users - ProductFTW #44 URL: https://www.productftw.com/productftw-44-why-great-support-creates-loyal-users/ Last updated: 2026-06-04T19:27:34.000Z As a product manager, my job does not end when a feature is built and shipped. A truly great product experience extends beyond the UI and core functionality. It includes how users interact with customer support, how feedback loops back into product improvements, and whether users feel heard and valued long after onboarding. Lately, I have been using [Linear](https://linear.app/?ref=productftw.com), and I cannot get over how seamless their customer support experience is. If I notice an issue, I can easily submit feedback within their portal. Within 24 hours, I receive a thoughtful response, either troubleshooting help, further clarifications, or an acknowledgment that they are adding it to their backlog. In some cases, I have even seen my issues fully resolved within a day. Experiences like these do not just solve problems; they create loyalty. I have found myself recommending Linear simply because their responsiveness has impressed me. That is the power of great customer support. It does not just help users; it turns them into advocates. As product managers, it is easy to focus solely on feature delivery and execution, but we must also think about what happens after launch. How do we ensure that customer support teams are empowered to delight users? How do we capture user feedback in a way that leads to meaningful improvements? And how do we create processes that prevent product managers from being a crutch for every support request? These are not just support issues. They are product issues, too. ![A digital animated-style image of a man sitting at his desk in a home office, looking at his computer screen while talking on the phone. He has a focused expression, possibly troubleshooting or discussing something important. ](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-27-10.15.12---An-animated-style-image-of-a-man-sitting-at-his-desk--looking-at-his-computer-screen-while-talking-on-the-phone.-He-has-a-focused-expression--possibly.webp) I wonder if this AI image is talking to an AI customer service agent # Customer Support is an Extension of the Product Experience Many companies think of customer support as a cost center, but in reality, it is one of the strongest differentiators a company can have. If a product is well-supported, users will overlook small issues and stay loyal because they feel heard. On the flip side, even the best products can lose customers if the support experience is frustrating. I see this all the time. One of my biggest frustrations is when I call into a support line and cannot reach a human. AI-driven IVRs and chatbots are useful for simple problems, but most of the time, if I am calling, it is because my issue does not fit into a script. When companies over-rely on automation without an easy path to a real person, they create friction and frustration, no matter how great their product is. As product managers, we need to think about customer support as part of the entire user journey, not just something that happens after launch. # Creating a Strong Feedback Loop Between Product and Customer Support One of the biggest challenges for product and support teams is ensuring the right feedback gets back to product while also equipping support teams to answer questions without relying on product managers for everything. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Key Touch-points for a Strong Feedback Loop 1. **Slack or another direct communication tool**: A shared Slack channel between product and customer support allows quick discussions for urgent or high-impact issues. The key here is balance. Product should not be constantly fielding support tickets, but having a place where customer-facing teams can flag major trends is crucial. 2. **Shared Internal Documentation:** Support teams should have easy-to-access internal documentation that helps them troubleshoot issues without escalating to product. This could be an internal wiki, Slab page, or an FAQ document that explains common issues, known bugs, and workarounds. If support teams repeatedly ask the same product question, that is a sign the documentation needs improvement. 3. **Regular Feedback Syncs:** A bi-weekly or monthly meeting between product and customer support helps identify patterns in user-reported issues. This is where product can distinguish one-off complaints from high-priority usability issues that need to be addressed in development. 4. **Tracking User Feedback with the Right Tools:** I have not personally used a perfect tool for tracking customer feedback, but a Zendesk-to-Slack integration is one of the more common ways teams surface major support issues. Ideally, a company would have a centralized system where product can see patterns in reported issues rather than relying on support teams to relay them manually. # Turning User Issues Into Meaningful Product Improvements Collecting feedback is only useful if it leads to action. The challenge for product teams is knowing what feedback to prioritize and how to document it in a way that actually drives improvement. 1. **Focus on Impact, Not Just the Issue Itself:** Simply logging a bug or request is not enough. Product managers need to understand why it matters. Two users reporting the same problem may have completely different levels of impact. 2. **Capture What Users Expected to Happen:** The most useful feedback is not just that a feature is broken but also what the user expected to happen. This insight helps product managers pinpoint friction points and design smoother experiences. 3. **Make Room for Continuous Improvements:** A healthy product delivery cycle should always reserve time for addressing bugs and usability issues. A good rule of thumb is to dedicate eighty percent of time to new features and twenty percent to issue resolution. This ensures that users feel improvements over time rather than just new feature rollouts. # The Real Question: Are You Making It Easy for Users to Stay? At the end of the day, customer support is not just a function. It is a critical part of the product experience. You can have the most intuitive UI, the smoothest onboarding flow, and the best core features, but if your users feel frustrated when they need help, they will leave for a competitor who listens. Linear understands this. Their response times, thoughtful follow-ups, and transparent backlog management make me want to keep using their product. Their support team is not just resolving issues. They are reinforcing trust. So the real question is not just, How great is your product? but rather, Are you making it easy for users to stay? That is what separates good products from truly great ones. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Choosing a Task Management Tool as a Product Manager - ProductFTW #43 URL: https://www.productftw.com/productftw-43-choosing-a-task-management-tool-as-a-product-manager/ Last updated: 2026-05-18T21:41:56.000Z If you are a product manager, there is a good chance that at some point in your career, you will be asked to choose a task management tool for your engineering team. I’ve picked task management tools five times, and I can tell you – there’s no perfect choice. Someone will always be unhappy. ***That’s just reality***. I have tried almost everything, from Asana to Jira to Monday to Linear to Basecamp. Every tool has flaws, and every tool has strengths. The challenge is finding the best option for your team while understanding that no choice will ever be perfect. ![A digitally illustrated image of multiple people holding up signs with various project management software logos, including ClickUp, Basecamp, Jira, Asana, Monday.com, and others. The illustration depicts a crowd, with some signs partially obscured.](https://www.productftw.com/content/images/2025/02/Frame-4-3.png) It's like a game of task management BINGO! ## The Spectrum of Task Management Tools Task management tools exist on a spectrum. Some are highly structured, requiring deep customization to make them work for your team, while others are extremely flexible, allowing you to shape them however you want. Where a tool sits on that spectrum affects how it will work for your team. At the most structured end, you have Jira. It is designed to handle complex workflows, permissions, and tracking, but it comes with a learning curve. On the other end, you have Asana, which is incredibly flexible and easy to use but lacks the structure needed to enforce consistency across projects. In the middle, you have tools like Monday and Airtable, which lean more toward project management, and then there is Linear, which tries to balance structure with ease of use. None of these tools are inherently good or bad. They just have different strengths and weaknesses depending on what you need. ## How to Evaluate What Your Team Needs The best way to determine what tool is right for your team is to create a list of must-have features, nice-to-have features, and deal-breakers. Every team works differently, and what is essential for one team may not matter to another. In the past, when assessing tools, I have gathered input from various stakeholders across product and engineering to compare our needs against different tools. This process helps clarify why one tool meets the majority of our needs, even if it is not perfect. The goal is not to find a tool that everyone loves but to find one that creates the fewest obstacles for the people using it every day. At the end of the day, the tool is only as strong as the team using it. Even if a tool is perfect on paper, it will fail if people do not adopt it. A less-than-perfect tool can work well if the team understands how to use it effectively. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Jira: Structured but Complex Jira is often considered the default for engineering teams, and for good reason. It is powerful, scalable, and integrates with almost everything. It provides a structured way to manage tickets, track sprints, and enforce workflows. The problem is that it can feel like it was built for administrators rather than for everyday users. Jira is flexible, but that flexibility comes at a cost. If you want to customize it to fit your team’s workflow, you will need to spend time learning how Jira works at a deep level. More often than not, teams need a dedicated Jira administrator just to manage security settings, customize workflows, and make sure everything is running smoothly. That level of complexity makes Jira frustrating, especially for teams that do not have someone dedicated to managing it. Understanding how to modify templates or set up new workflows requires knowing the full history of the product. If you do not know how Jira has evolved over time, making changes can feel like walking through a maze. ## Asana: Flexible but Lacks Structure Asana sits on the other end of the spectrum. It is one of the most user-friendly task management tools, and that is one of its biggest advantages. It has an intuitive UI, allows for infinite nesting of tasks, and makes it easy to create and manage projects. The problem is that Asana is almost too flexible. Because it does not enforce a specific structure, every team will use Asana differently. Some teams will create a clear system with well-defined processes, while others will end up with scattered tasks and inconsistent workflows. The lack of standardization can become frustrating over time. Another major issue is that Asana is not great for tracking timing. Unlike project management tools that provide built-in features for tracking timelines and dependencies, Asana makes it difficult to get a high-level view of progress. ## Monday and Airtable: Better for Project Management but Awkward for Engineering Monday and Airtable fall somewhere between Jira and Asana. They offer more structure than Asana but are not as rigid as Jira. They allow teams to track progress, create charts, and manage projects with a level of flexibility that works well for business operations. The problem is that they do not always feel natural for engineering teams. Monday and Airtable are designed for more general project management rather than software development. Their interfaces make them great for tracking high-level initiatives, but they do not always fit the workflows that engineers are used to. ## Linear: A Strong Balance of Structure and Flexibility Linear is my favorite task management tool at the moment. It strikes a good balance between structure and flexibility. It has a clean UI, a well-designed mobile and desktop app, and a strong developer-first approach. Unlike Jira, it is designed to be fast and intuitive, with hotkeys that make it easy to create and manage tasks without extra effort. Linear does have its limitations. One of the biggest is that it forces all unfinished sprint tasks into the next sprint cycle rather than letting you complete tasks within the original sprint. If you have a sprint that overlaps due to user acceptance testing or quality assurance, visibility can become difficult. It is also not meant for deep project management, so if you need advanced tracking features, it may not be the best fit. ## No Perfect Answer, Just Trade-offs After selecting task management tools multiple times in my career, I have realized that there is no single right answer. Every tool has flaws. Every tool has strong features. The key is understanding what your team needs and where they fall on the spectrum of structure versus flexibility. The best way to make a decision is by gathering input from stakeholders, defining the must-haves, and comparing tools against that list. Every time I have evaluated tools, I have done so with the assumption that the primary users would be product and engineering. I have not used every tool, but from my experience, the right choice is the one that best meets the needs of the team while being easy to adopt. A tool is only as effective as the team using it. The strongest teams are not the ones with the best tools - they are the ones that know how to use their tools effectively. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Decision Fatigue - ProductFTW #42 URL: https://www.productftw.com/productftw-42-decision-fatigue/ Last updated: 2026-05-10T23:40:28.000Z As a product manager, your day is filled with decisions. Some are big, such as strategic calls that shape the roadmap, prioritization discussions, and trade-offs between user experience and business impact. Others are small, like choosing between button colors or finalizing microcopy. Individually, none of these decisions feel overwhelming. But collectively, they stack up. Some days, it feels like you are making hundreds or even thousands of micro-decisions, and every single one has the potential to impact your users. That is a lot of responsibility, and it can become exhausting. ![A semi-realistic animated illustration of a stressed and exhausted person sitting at a desk, head in hands, surrounded by thought bubbles filled with question marks and checkboxes. Arrows point both inwards and outwards, symbolizing external pressures and internal conflict. The muted color palette and chaotic background emphasize decision fatigue and mental overload.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-05-09.33.16---A-semi-realistic-animated-illustration-representing-decision-fatigue.-A-tired-and-overwhelmed-person-sits-at-a-desk--surrounded-by-multiple-thought-bu.webp) TFW every choice feels like the wrong one... and also the right one. Recently, I hit a point where I had made so many decisions that I stopped caring. I was not thinking about the user. I was not considering the impact. I was just making calls to get things done. That is when I realized this is probably something every product manager experiences at some point. So what do you do when you hit that wall? When you are at the end of your rope and decision fatigue has drained every ounce of energy from you? How do you reset, get back to a place of thoughtful decision-making, and ensure you are doing what is best for your users? Here is what I have learned. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Step Away Intentionally One of the biggest lessons I have learned is that stepping away does not always mean completely disconnecting from work. There are ways to take a break while still contributing in a meaningful way. For me, that means shifting my focus to non-client work. This could be writing for ProductFTW, learning better practices in Figma, or working on our website. These tasks still add value, but they allow me to take off my product manager hat for a while. They let me engage with my work in a different way, one that does not require constant decision-making or prioritization. However, sometimes what you really need is a complete mental reset. That is where work-life balance becomes important. Finding an outlet outside of work can help clear your head and bring fresh energy to your role. For some, that might be: - Reading a book, whether fiction or non-fiction - Taking a walk outside or exercising - Doing something creative like writing, painting, or playing an instrument - Spending time with friends or family to step out of the product mindset entirely The key is recognizing when you need to step away in a way that still feels productive versus when you need a full break. Both are valid, and both can help you reset so you can return with a fresh perspective. ## Zoom Out and See the Bigger Picture Decision fatigue often comes from getting stuck in the weeds. You spend so much time making small, granular calls that you lose sight of the overall picture. When I start feeling this way, I know it is time to take a step back. Instead of obsessing over whether an icon should be on the left or right side of the screen, I force myself to look at how all these micro-decisions are shaping the whole product experience. Ask yourself: - How does this fit into our broader strategy? - Are we over-optimizing for one tiny detail at the expense of the bigger user journey? - Will this decision even matter in the grand scheme of things? Sometimes, zooming out makes you realize that the thing you are stressing over is not actually that important. When that happens, you can redirect your energy to decisions that truly move the needle. ## Get a Second Opinion Without Offloading Your Responsibility If you are so mentally drained that you genuinely cannot care whether the button is blue or a simple text link, ask someone else. Getting a second opinion from a designer, engineer, or fellow product manager can be a helpful way to break decision fatigue. It acts as a buffer, giving your brain a moment to pause. However, there is a fine line here. Asking for input is great, but do not use it as a crutch. At the end of the day, your job is not just to get decisions made. It is to own them. If you are constantly delegating every small choice, you are not solving the problem. You are just shifting the weight of decision fatigue onto someone else. Instead, use feedback strategically. - Gut-check a decision when you are unsure, but commit to making the final call. - Collaborate with your team on bigger product choices, but do not push off ownership. - Trust your instincts when you already know the answer. Second-guessing will only drain you more. ## Protect Your Decision-Making Energy Not every decision needs the same level of attention. One of the best ways to manage decision fatigue is to be intentional about where you invest your energy. Prioritize the decisions that have the biggest impact, and do not waste mental space on the ones that do not. For example: - High-impact decisions that are worth your energy include anything related to core user experience, long-term product strategy, or major technical trade-offs. - Low-impact decisions that are not worth overthinking include button colors, minor layout tweaks, and internal tools with no user-facing impact. If you can automate, standardize, or delegate the low-stakes decisions, do it. Save your energy for the choices that actually matter. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Final Thoughts: Your Decisions Matter Even When They Feel Small At the end of the day, every decision you make impacts someone. It might feel like just another micro-decision in a long list of daily calls, but to the user on the other end, it could shape their entire experience with your product. That is why it is so important to recognize when you are feeling fatigued, step away when needed, and find ways to re-engage with your work. Because the best decisions, the ones that truly make a difference, come from a place of clarity, creativity, and thoughtful intention. When you reach that place again, you will remember why you love this job in the first place. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Managing the Legal Files - ProductFTW #41 URL: https://www.productftw.com/productftw-41-managing-the-legal-files/ Last updated: 2026-06-04T19:27:31.000Z One of the more mundane, but important tasks in product management is managing legal documents that are a part of the product. Every product has some legal document. For most web applications it might be as simple as a privacy policy and a terms of use document. For fintech products, like we build at [Totavi](https://www.totavi.com/?ref=productftw.com), a product might have a half-dozen documents or more, such as account agreements, rewards program terms, e-sign agreements and more. Each of these files needs to be tracked and managed carefully. It seems easy, but I have repeatedly been tripped up by finding that we posted the wrong document to the app or let something get out of date. In addition to making sure users see the correct document, you may need to alert users to changes and track which users saw which document (and, in turn, what you are allowed to do with that user’s product or data as a result). ![A cartoon-style illustration of a frustrated man with glasses in a messy office, hands on hips. Papers overflow from desks and cabinets, flying through the air, emphasizing the chaos and disorder.](https://www.productftw.com/content/images/2025/02/DALL-E-2025-02-05-09.21.52---A-cartoon-style-animated-illustration-of-a-disgruntled-man-standing-in-an-office-space--facing-forward-with-his-hands-on-his-hips.-He-has-a-frustrated.webp) At least we have computers now... If you want to build an iron-clad system for managing documents, there are a few straightforward tactics you can use: 1. Name all documents with an internal tracking code. For example, your privacy policy could be tagged with “LEGAL-PP-20250206-v2.0.2” to indicate the following: 1. LEGAL: just a prefix 2. PP: “privacy policy” 3. 20250206: the date of the update in YYYYMMDD format (which is the only correct format 😜 ) 4. v2.0.2: a version number 2. Include the document tracking code in the document itself. For example, you could put it in the footer of a multi-page PDF (or other document format) or simply at the end of a webpage. 3. Keep a copy of all files in a cloud storage solution with version control (such as Dropbox or Google Drive). 4. Post all documents for users to view to a stand-alone content delivery network (CDN) location, such as a separate AWS S3 bucket (named something like “legal”). I know, this is a lot of process, but it’s going to save you down the road and isn’t that hard to do. It always feels like these things will be easy to manage, but then, as the product grows and things change, they start to get unwieldy. Number 4 above is especially important, as you do not want to have to ask engineering to do a deployment to update documents. By placing the assets in a CDN location, you can enable a product or operations person to update without a deployment. In the website or application routes, you should enable any user who should see the latest to link to an alias for the current version. For example www.example.com/legal/privacy-policy is a location you can depend on and easily code to. That can be set in the CDN to route to www.example.com/legal/privacy-policy/LEGAL-PP-20250206-v2.0.2.pdf as the actual source file. Why not just replace the file? Well, there are cases where you may need to show users a prior version. This brings up the second big topic: tracking. When a user signs up for your product, you should store the version of the terms in the user metadata (e.g., the user table) so you know what they agreed to. Some legal changes may be something you can force on your user (for example, a blocking modal that you must agree to new terms to continue). You can easily use the user metadata to trigger actions in your application. On the other hand, especially in financial services, you may have to give users time to use the product under old terms before they have a choice to close their account or agree to new terms. For example, if you are operating a credit card and change the rewards terms, you may tell your users they have 90 days to continue or to agree to new terms. In that case, you will need to show the user the cardholder agreement and rewards terms that currently apply to them, not just the latest. Depending on your product, the legal changes, and your legal team, you may also simply notify users (either or both of via an in-app notification or via a push). Again, you need to be able to build a list of who needs this and who saw it. It’s usually not enough to just post to your site for a month (“we just changed our terms”). With some additional attention to detail and a clear plan, you can ensure your product stays compliant, you reduce risk to your organization, and ultimately provide a better user experience, by planning ahead on legal documents. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. *Part of the* [*Fintech Product Management Field Guide*](https://www.productftw.com/fintech-product-management-guide/) *— ProductFTW's writing on what makes building card, payment, and banking products different.* ### Product Talks with Felix Del Rosario - ProductFTW #40 URL: https://www.productftw.com/productftw-40-product-talks-with-felix-del-rosario/ Last updated: 2026-05-22T01:57:24.000Z For our seventh post in the [Product Talks](https://www.productftw.com/product-talks/) series, we’re featuring Felix Del Rosario, VP of Product at The Zebra. I first met Felix on the soccer field, proving you never know when or where you’ll meet incredible people. Though we’ve never worked together or even been in the same industry, it was fascinating to discover how similar some of our experiences are and how universal product methodology can be. --- ![A promotional graphic for 'Product Talks' by productftw. The image features a black background with a neon-style speech bubble containing the words 'Product Talks' in glowing yellow text. Below this, there are two headshots: one of Matthew Goldman, wearing glasses and a blazer, and another of Felix Del Rosario, wearing glasses and a black shirt, both against a red-to-yellow gradient background. The tagline at the bottom reads, 'It's like a podcast, but you have to read it.'](https://www.productftw.com/content/images/2025/02/Felix.png) Talking product with Felix! ***Ellen*** *Hey Felix, how’s it going? It’s been a while since we last chatted; what have you been up to?* **Felix** Hey, yeah, it’s been ages! I've been at The Zebra for the last five years. I've been loving it. It's had its challenges, but I had been looking for such a long time for a place where I could be for an extended period, and this one has really worked out for me. ***Ellen*** *You were at Indeed before, right?* **Felix** Yeah, I was at Indeed until 2013\. Then, I went to a company called Small World Labs, which is now Personify, I believe. After that, I went to Spare Foot, which is now Storable. Then I did a short stint at Web.com, and now I've been here at The Zebra for five years. ***Ellen*** *Yeah, that's a lot of hopping around in a decade.* **Felix** It was a lot. I moved here from the Dominican Republic, and I basically had to start my career again. What I had been doing there had not worked out for me in the US. I wanted to be a Project Manager or Developer, and neither of those careers were working. So I took an entry-level job with Indeed, and I just ran into someone who was a Product Manager, and they opened my eyes to the career. I initially thought growth would come from switching positions, but now it seems like it comes from staying in one place for a long time to prove myself. Web.com was a place where I thought I'd do that, but that was a disaster. I did learn a lot, but I had to get out of there. And actually, at some point, they showed me the way out. They sold the business unit I was on. And then, after that, I left. The second spot I came to was The Zebra, and then I was like, “Okay, maybe this one will last five years.” And here I am! I could be here for ten years, and I’ll be happy. ***Ellen*** *That’s amazing! For a little bit of background, could you please explain your role, where you're working, how large the company is, and what your team looks like?* **Felix** I work at The Zebra, the United States’ largest online marketplace for insurance. I am a VP of Product, meaning I lead the Product practice, which includes Product Management and Design. The company currently has about 250 people, and my team has seven people and me. ***Ellen*** *Wow, that’s a big team. Thank you. I do have a list of questions, but I’ll start with what you were just talking about: getting into product and what career path you took to become a PM. It kind of sounded like you were a Developer/Project Manager and then just had the right timing with Indeed and that Product Manager you met. Is there anything you'd want to add to that?* **Felix** I think Product used to be a career people kind of fell into. Even when I fell into it around 2011-2012, it wasn't clear what I was supposed to be doing. You mentioned before we started that in the last 10-12 years, there’s been a development of content and content creators that have published all their knowledge from having been the first people that did this kind of product management, where we were all still figuring stuff out. But now, you can go to school and pretty much come out of school as a product manager. That wasn't something that people were able to do when I was starting as a PM. So the landscape has changed a lot. I think the Associate Product Manager position also has lost some relevance, which was how I started. It's just a different career to get into compared to when I did. ***Ellen*** *What made you want to become a product manager?* **Felix** One of the things that I struggled with as a project manager was leading projects that were, in my opinion, going to be unsuccessful. Project managers, at least in the capacity I had been in, don't get to decide if the project is done or not. You're basically asked to make sure the project stays on track, stays at cost, and that the resources are being used. I’d always felt that the person leading the project could easily be the person making the decisions on what gets done and should be held responsible for that as well. While working at Indeed, I discovered that that combination was called product management. I immediately knew that that was what I needed to do. I found the way at Indeed; there was a role that opened up, and I went directly to the hiring manager and asked if I could have it. ***Ellen*** *That’s awesome. And, when you talk about product management, what does it mean to you? Because obviously, there are kind of blurred lines between project management and product management.* **Felix** Yeah. I'll answer your question and then give you more of the commentary that has been used and my problems with it. So, it can depend on where they work, but I'm going to stick with tech, B2B, B2C, or combos of those. But, product managers are responsible for understanding business needs and consumer/customer needs and translating those to business value. That is the biggest thing we do every day. And yes, that involves managing projects, but it also involves talking to customers, getting on sales calls, interviewing people, and then translating all that stuff into viable, feasible requirements for your business that align with your business goals. Product managers have one of the most unenviable roles because they have to work with multiple teams and influence everyone without actually managing anyone, despite having “manager” in the title. And that is very hard. They need to be good at framing, explaining, and aligning people, and they really need to be good at tying back what they did to the things they said they would do, like answering this problem for this customer, and also show that it connected to this business value that they promised. So that's the day-to-day. The key difference between a product manager and a project manager is (and again, I'm thinking from my experience being a project manager) that you weren't responsible for understanding the *why* behind the things we were working on; it was more so just making sure the things got done. Something that has been permeated into our culture of product management is that we're all mini CEOs. And I get what people are trying to explain with that, that you are responsible for driving business or creating value for a business. But there's so much more to being a CEO. I think product people should be allowed to focus on the product alone. Once you start telling them that they’re mini CEOs, people with egos start growing into places and trying to do things that they shouldn't be focused on. Product people should be focused on addressing consumer needs to build business value. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ***Ellen*** *Wow. It is enlightening speaking with you because I feel like I've been in this product bubble, surrounded by people who have all come from the same cohort of product management. Sometimes, when I've been interviewing in the past for jobs, people haven’t really understood what product management is. And so to hear someone who's not in the fintech world at all and not in the same product realm that I've been in say the same things that I, and all my peers, believe in makes me feel really relieved. I sometimes feel like we're the only army that thinks that the product manager is not the CEO. Actually, the product manager needs the CEO to help with decision-making because PMs can't be responsible for everything. So it's really awesome to hear you say that because I have felt like it was just a small group of us who believed this, but it’s actually other people in the industry as well.* **Felix** I'm glad that this is becoming more of a rallying cry for us and our craft. There have been things about product owners, managers, or leaders owning P&Ls, and I think it makes sense. Again, I get why that has been a thing. You should understand how much work you're putting into the value you're getting out of things. But is owning the P&L and learning how to manage it the best tool to do that? I don't know. ***Ellen*** *I think that's why I often see product managers who have aspirations of being CEOs or have been told that they should try to start their own company. But they realize very quickly that it's either for them or isn't for them. It can be a binary thing. You could just be a product manager, or you can just be a CEO, and it doesn't need to be intermingled at all.* **Felix** Yeah. ***Ellen*** *So the next question I have for you is, do you have any advice for new product managers?* **Felix** I have a lot. It's very dependent on the context and the person, but generally speaking, I think putting your ego aside is very key in the beginning. Product managers do have a lot of influence, especially in product-led companies or product-centric companies. And you can get really hung up on, “I am a decision maker, and I am going to make things happen.” Early in your career, it's really important to just learn and absorb how businesses are run, how your business or where you're working is run, and the industry it fits into while you get at-bats with simple things. Early on in my career, I got at-bats with relatively easy things like optimizing a funnel. It was really good to get a lot of practice just doing relatively simple work as a product manager while I learned the business and the industry I was in. The other thing I would say is to learn from industry leaders. But I think you need a mentor who can help you filter out the noise as well. It's very easy to hear folks like Marty Cagan or even read one of those books, like *Inspired* or *Transformed*, that isn't even meant for ICs, and go into a company and say, this is how things are done. I think you have to be more pragmatic. Not all companies are on the way those books are written. ***Ellen*** *Yeah, I feel like there's not enough focus on having your own PM style. Often, people are just trying to emulate what someone else has done, which is a good idea because they've done some really incredible things in their career, but unless you follow the same exact career path, it's not going to work out for you. So, you should be taking bits and pieces from everyone that you're interacting with and seeing how they've been successful and making it your own instead of just trying to copy it.* **Felix** I agree. And then one more thing on this one: when looking for jobs, find a product that, especially early on in your career, you respect. There, you will probably find people that you respect, and you can learn from them as well. It makes a job search harder, I understand that. But I think it helps a lot to make sure that you establish your career at a place where believing in the product is not an issue and you can focus on the mechanics of product management. ***Ellen*** *You just gave me a book idea, mixed with the talk about Marty Cagan—“Uninspired.” It's like that feeling when you're working for a product that you don't believe in, and you’re trying to make it come to life over and over and over again.* **Felix** As a junior PM, that's very hard. Like, top of learning product, I have to survive. ***Ellen*** *Exactly. And I don't even believe in it. So, what has been your biggest challenge as a PM, and how did you overcome it?* **Felix** Early in my career, I had many moments of “I don't know what I'm doing,” and I didn't really have a network to help me see how I could change things or be better; it was very demotivating. I actually tried to get out of product management after having done it for a year and a half or two. But as I interviewed, people told me, “You are a product manager. You need to keep doing this.” So that was very challenging. I think the hardest thing for me was taking the step from just learning how to be a product manager to knowing how to do it and how to position myself to create value and not just practice with a product. And that part was really hard. And then, deeper into my career, what's become harder is learning how to keep a team motivated, how to keep a team moving along in tandem with our business, and how to create alignment between our investors, our exec team, and the people working on the product. So, the challenges have changed, but there's always something that is hard to do. Hopefully, all of us are working in roles where if something is challenging, you're keen on learning about it. In my career, there have been moments when I’ve wondered if the product was actually necessary, and that was also really challenging. ***Ellen*** *Why did you find that challenging? I'd love to hear more about your opinion on that.* **Felix** It's easy to hire a product person, decide what their work is going to be, feed it to them, and have them deal with the Scrum Master of the Engineering role, basically. And often, I felt like, well, what's my role then? When I pressed on that, people made it clear that my role was to just run the projects they had decided on. As you can remember, that's why I didn't want to do project management anymore. Then there’s the lack of respect, too. I've worked at B2B companies where I tried to get in front of sales so that I could understand why the sales team translated customers' needs into individual, specific features that they wanted me to build. And they told me, “No, no, no, we talk to our customers; you don’t need to.” I’ve never been specifically told there’s not going to be a product role, but the product role that I believe needs to exist is not allowed to exist. I think about that like, “Well, why do you have Product, and why am I here?” ***Ellen*** *That is a very relatable experience, and it makes it even more challenging because you're then trying to justify your role while also creating value, which is really challenging to stay motivated.* **Felix** I also look to the future, and I keep saying this, and it may be silly, but we went to the moon and there were no product managers involved. I have a strong belief that engineers can build products with good founders and good business-minded people. I have a slight fear that Product is not a 20-year career from where we stand today. So, I'm constantly looking at how we can continue to shape this and how I can influence how Product shapes itself, looking at the future as well. ***Ellen*** *Well, to have a healthy argument, some would say that there were product managers. They just didn't have the title. Right? Because there always has to be someone creating value and figuring out the best way to do something. Sometimes, it’s an engineer who acts as a product person, but there's always product management. But it'll be really interesting to see where things go.* ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Felix** Hopefully, it enhances what we do, but we're still participating in that. That's what I'm trying to help out with. ***Ellen*** *And AI is also led by product people, you know. But, moving on, what is a lesson you've learned as a PM that has changed the way you work, think, or collaborate?* **Felix** I hinted at this earlier: humility. Again, we've wrested this title and this role at companies, and this theory that we’re mini CEOs didn't help either. I think just being humble and listening to your customers, your stakeholders at your companies, or whoever you're working with is a big piece of advice. ***Ellen*** *Yeah. You know, it's funny you say that. At Totavi, we're a product-led company—we’re a consulting firm that helps people implement, basically. There are three of us who have been product managers, one who wants to become one, and someone who's product-minded. But the thing that we all have in common is that we're all a little bit self-deprecating. We have self-confidence, but we don't always believe in ourselves. So I feel like you need to have that natural balance of constantly questioning, "Is this good enough? Is this going to answer whatever the problem is?" Because if you think you're the best, that's when your competitors are going to overrun you, because everyone needs to think you're the best, not just you.* **Felix** I agree. And you can do all of this with confidence; we don't have to have this feeling of imposter syndrome every second of our lives. One of the tools we use at The Zebra is Teresa Torres’ Opportunity Solution Trees. The reason they're really great is because they have a specific outcome you're chasing. And then you create your opportunities as leaves on a tree. Then from those opportunities, you create your solutions. The next step is to list the assumptions you've made to arrive at that solution. Those assumptions become experiments that you run to check that solution. Then, when you arrive at that solution, and you're confident about it, the next step is to march that solution back up your tree to make sure it still aligns with the opportunity and that you still believe that opportunity addresses the outcome that you're seeking. That process allows you to continue to check yourself: Am I making the right steps? Am I making the right decision? Am I listening? Am I understanding the changes and assumptions I have made, and how we've tested and have new data on those? It gives you a way to do that confidently. I love having tools like that where people are able to check themselves but do so while moving forward and not getting stuck in spinning. ***Ellen*** *I love that. I haven't heard of that specific methodology, so I just took a note to look it up. I always love looking at new things like that.* *Okay, well, you just mentioned one tool. Wow, you're right on—you must have had these questions ahead of time. But the question is: What are three tools you use every day that you would suggest aspiring PMs learn, understand, or buy? This could be a certain methodology you use, a software or a tool, or a specific agenda, et cetera. Pretty broad.* **Felix** I’ll give you two sets because I use different tools now than I did when I was running a product every day. So right now, the biggest, most important things to me are, well, this one’s silly, but Slack. Jira Product Discovery has been really good for us. It's basically like free-form roadmapping and you can use it as you want. It's worked really well for us. I'm a big believer, even in an Agile world or at least for the Agile principles, I think documentation is really important. I don't think we should do 80% documentation and 20% work, but there should never be 0% documentation, especially around the decisions that product makes. I love tools that allow us to document stuff. Right now, one of my favorite tools that allows us to run an end-to-end A/B testing program is Eppo, which allows us to create our hypotheses, run our tests with all the metrics, and then put our conclusions all in one place. It's this massive hub of all our learnings and all the things we've done on our product. So I love that one too. That's from a leadership standpoint. I'm sure at the IC level right now, the tools that our teams are using would be things like I mentioned, the OST or Opportunity Solution Tree, which comes from Teresa Torres, who authored *Continuous Discovery Habits*. There are several tools in there that I'm probably forgetting, but the OST is the main one that we use. Our product lives and evolves around those trees, and the trees live in Miro. Thinking more about how we create value, I think the scientific process is vastly underrated. And it's funny because we learn it in primary school, right? Create a hypothesis, test your hypothesis, and understand if it is true or not. So that process, which, again, I remember as the scientific process that we learned in elementary school, is a big part of how I think good product managers think about their work. I've also liked Strategizer's Value Proposition Design Canvas. I haven’t had an opportunity to use it too much, but I think any company or any product person that can get to that and use it every day, even product marketers or any type of marketer, I think it has the potential to create massive value for companies and consumers as well. ***Ellen*** *Awesome. I love all those. How do you manage cross-functional work and communication across different teams, and how do you ensure alignment?* **Felix** So, on the alignment piece, we create goals, and we forecast against those goals, and then those trickle down. Product is lucky because, at the company I work at, the product goals are the company goals It’s very product-centric. So, for us, it's almost natural. Where we struggled a bit is creating alignment around those goals with the rest of our stakeholders and the people we work with. But again, since they’re the company goals, that alignment becomes a little easier, too. Goals are the best way, in my opinion, to create alignment. I think goals can be interpreted differently by people. So, we have sessions where we explain and understand what the goals are. These sessions are at the level of actually working on creating the product; what do they mean, and why are they important? And everyone working toward those goals needs to understand those things. And some people care less, but at least then they've heard the spiel. And then, sorry, I stuck on the alignment piece. What was the first part of your question? ***Ellen*** *Managing cross-functional work and communication.* **Felix** That's so hard. We live in a world where communication is construed as a Slack message. And sure, that is a type of communication, but what is true communication? To me, it's something that is more than just a message. To me, it's a concept that you fully understand and get behind or can disagree with. That type of communication, for us, happens in working sessions, again, around the methodology of squads or trios leading the product end-to-end. We have a process that allows us to, around one outcome or goal, bring all the stakeholders together and create solutions. And I don't know if there's any other communication that matters more than that. We arrived at the solution, and we arrived at it together. We're all going to go together to where it is. And the alignment is created because we're all marching toward this goal. Then, you need to document that. As I said, we use Confluence or Jira Product Discovery for that. ***Ellen*** *I'm getting the impression that you're very data-focused, which is amazing. Is this a cultural trait of Zebra, or is it something that you've had your whole career? Do you kind of foster the environment as you go?* **Felix** I won't work for a company that isn't data-driven. So, as part of my interviewing process, earlier in my career, I would try to understand how good your data was, but that became less important than whether you use whatever data you have to make decisions. Indeed—being the first place I worked as a product manager—created a very strong feeling in me that this is the way to work. And it's been validated over and over at the other places I've worked at. In the places where I really liked it and the places where I've struggled. ***Ellen*** *From the perspective of the startup world, you always lack data and have an abundance of need for speed. So, you try to bridge that gap to make decisions quickly, but also with very little data. So I love hearing about your experience because I'm like, man, that is like the pie in the sky for me. I would love an experience where it was like, yeah, let's do this whole tree, make assumptions, and actually build a test. Do you ever feel like you're pressed because of speed or the need to move quickly?* ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Felix** Yeah. And that's a good point. Earlier in my career, I thought data was all quantity. I needed to know the numbers and I needed to know how many people have used this thing and what numbers that produced. But smaller companies don't have that, right? They don't have that advantage. So I learned, too, that qualitative data is just as important, especially in those earlier phase companies or even earlier phases of products at mature companies. I'm thinking about a product that Google developed that had little traction; I think it was called Google Buzz, maybe ten years ago now. That didn't even have 1% of the usage that Google search has. I'm sure they created some set of signals from the data and/or talking to people that they were heading in the right direction. Then, I think continuing to be ruthless about finding whatever signals you can to track against is also important. There's a story about a company that basically sold to white hat hackers, and it's a tool. But it’s not like they sell to hundreds of people or thousands of people; it's more like dozens of customers, but they pay quite a bit, so they don't need many. When they were trying to understand, from the data, what they should be doing, it was really hard for them to understand very clear actions like, “We caught this thing that was potentially a security problem.” They maybe had three of those a year. Imagine trying to develop that product as a product manager. But what they found is, out of three things that they discovered, there were dozens of rabbit holes that they had gone down and found nothing. They eventually found that one of the actions that seemed to be showing progress was copy-pasting. So they started capturing copy-pastes as a signal that the people using this product were finding value from it; they were copy-pasting stuff from this product to somewhere else. So they had way more copy-pastes than they did, like, “This security threat had been found.” So my advice there is to keep pushing to find leading indicators to the big things that you are or will be chasing. ***Ellen*** *I love that example. What is the most rewarding part of being a PM for you?* **Felix** When consumers get their needs solved. We just did this thing at The Zebra, where we started separating the reviews that we get from consumers buying through an agent from reviews we get from customers buying through our online product. We have an agency that helps us sell our policies, and they do a lot more sales than the online product does. But we've developed this online product in the last couple of years, and I really wanted to know how it’s doing and how people are reviewing it. And just this week, we got our first confirmed review from someone who purchased through the online product that we've been working so hard to build. And it said exactly what I thought we were doing for consumers: “It was easy. It saved me time. It saved me money. I was confident going through this product. Five stars.” I was like, “ Oh my gosh, this is it! We just need to do this a lot more.” Bringing it back to my Indeed days, we launched this thing from a Hack-a-thon called Got a Job. When people finally landed a job through Indeed, they would come to this thing and say, “I got a job, and thank you so much.” It was just a steady stream on this subdomain we had created, and it demonstrated the value we brought to consumers, which was to get a job. At Web.com, when you entered the office, there was a giant screen with a map of the United States. It showed the sales that we had generated from the customers we were selling our lead gen product to, and they would shine as dots on the map. And every day, I thought, this is what I'm helping. I'm helping small businesses be successful. To me, nothing else is bigger than that. As an individual contributor, as a leader, you don't have that many opportunities to drive those things directly. It becomes more about the success of your team, both in what they do every day and in lighting up those dots on those maps or getting those five-star reviews. But also, every year, I celebrate the people who have stayed and continue to be in my product org; that’s massive to me as well. ***Ellen*** *Yeah, it's a two-way street, right? They have to choose to want to continue to work for you, you know. What do you think the future of product management will look like? I know we kind of talked about it, but what do you think?* **Felix** I don't know. It's kind of tumultuous now. I think it's so great that you brought up the whole book culture. For a while there, I was reading a lot of product books, and at some point, I was like, what am I doing? The best way to do this is just go do it. But some of us don't have that opportunity. So that's why books are good, too. But I do think these early leaders, I'm talking like the 2000s, maybe late 90s, are starting to have an influence on how we shape Product. And to your point, a lot of those opinions are coming from larger, very successful companies. I mean, if you're writing a book, you have been successful. I think that we're going to get influenced quite a bit by that. Leaders and roles like mine are going to continue to have to be like, “Okay, but let's tone it down. Reality is more like *this*.” So I'm a little nervous about Product becoming this bland, homogenous thing that is done the same way everywhere because three or four people said that was the way to do it. I'd like the future to be one in which we continue to create pockets of opinions, loosely held opinions, and strongly held opinions and discuss them. I love going to the product management subreddit on Reddit; it's grassroots product management at its best. I want to see that future continue to grow. ***Ellen*** *I feel like the information is extremely valuable; I'm not discounting Marty Cagan or Inspired, or even Lenny; I can't pronounce his last name that starts with an R. But that was during the tech boom, and things were vastly different than they are now. Like, the tech boom has passed, and it's more difficult than ever to have a successful product. There's always a million of them where, back in the day, Google was one of three that were actually doing what they were trying to do and solving the problems that they were trying to solve. Now you're one of a million trying to solve these problems, and it just looks so different.* *So, I am really curious to see how it evolves. I haven't been on the product manager Reddit. So now I'm thinking that maybe I could find some inspiration there because, in some ways, it feels like it's a dying art. But the core of a product manager is problem-solving. My sister is an artist. She loves to paint. For me, I feel like I am my most creative when I'm problem-solving. I can only do that through product management because I'm not the one who's physically building something, you know? And so it's my form of artwork.* **Felix** That's a good way to put it. I was watching this video on TikTok of a trucker recording themselves from a drone going down this massive winding hill in Caprock, out in west Texas. And it was just beautiful. This guy was driving down this winding road and was in this amazing environment, surrounded by this canyon and all this red rock. And I was like, “I want to be a trucker.” It’s just a great thing when you're actually doing it—you know, you're driving, and there’s this scenery right in front of you, and look how beautiful it is, and you get to experience that. Obviously, these people also drive through the Midwest, which is just flat land. So, that video was an outlier. But yeah, I want to do tangible things, but I'm not great at them. And this is what is really great and what I found my passion in. I still think I'll be a barista at some point, maybe when I retire. ***Ellen*** *But that's the dream, though, you know, when you get to create something physical. But I think our job is harder because you're not managing something that's physical; you're managing something that's very much intangible, and you have to predict the future at the same time. And so you're trying to pull on these threads, and who knows if it's going to come to fruition. My husband is a hardscaper, so he builds walls or walkways or whatever, and he's doing the same type of problem-solving, but he gets to do it physically. Our approaches to how we’d go about things are almost exactly the same, but they're two vastly different industries. So it's really interesting to know that my skills are transferable if I ever want to go somewhere or because I need to switch things up.* *We just started a business, and I'm wearing the shirt today, Bucket and Blade. Part of it is regrading people's yards and whatnot. When you start a project, you have to go look at it and understand how it's going to work. How you're going to solve the problem, what equipment you need, and everything like that. Then you need to come up with requirements like, we need to get this here at this time, and we need to do this, and here's how we're going to measure the success. Like, did the water actually go into the drain? And so I think that there is hope for all product managers who feel like the industry is dying, that we've put ourselves in a position where we very much feel like the master of none. But the reality is we've really opened the doors to other industries for ourselves to step into and see that these skills are transferable.* **Felix** That's true. And honestly, too, as you're saying, understanding the needs and the requirements but then the next step of doing something that is really hard to undo. With software, it’s like, okay, well, that didn't work. Stop the test, turn the feature flag off, whatever. So, I don't actually know how much I want to do the real world. ***Ellen*** *Whenever I was trying to motivate my product management teams, and they felt like they were having crippling anxiety or something, I would be like, “Well, no one's life is at risk here. You're not messing with anyone's livelihood. So it's going to be okay if you mess up.” But yeah, you're right. In the real world, or should I say in the physical world, it's a little different.* *That’s all my questions. I appreciate you sitting down with me today. You're such a fantastic speaker.* **Felix** Yeah, no problem. This was fun. Thanks, Ellen! ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Product Talks with Jessica Marquez - ProductFTW #39 URL: https://www.productftw.com/productftw-39-product-talks-with-jessica-marquez/ Last updated: 2026-05-22T01:57:23.000Z For our sixth post in the [Product Talks](https://www.productftw.com/product-talks/) series, we’re talking to Jessica Marquez, one of two product principals at Totavi. I’ll never forget when I first met Jessica and the amazing timing that led to her being my first product manager at Wallaby. Handing the product over to her was a huge step for me and she was the absolute perfect person for it. I loved reminiscing with her and love working with her today. --- ![](https://www.productftw.com/content/images/2025/01/Jessica-Marquez-3.png) ***Matthew*** *What did you study in college? Did you know what product management was? Or, what did you originally want to be when you grew up?* **Jessica** No, I didn't know what it was. When I was in college, I got my BA in Interpersonal Communications, and I wasn't sure what I was going to do with that. I had the opportunity to study at USC after that, and I got my Master's degree in Communication Management with a focus on Online Community Development. With that, I thought that I was going to build a career in social media management, marketing, and community development. ***Matthew*** *How did you get into product from there?* **Jessica** I started my career in social media management and marketing. In the second startup that I worked at, the CEO and Founder had a background in Product. Similar to many startups, he was our original product manager. While working there, I felt like I didn’t have a voice in the products that I was marketing, and I had developed opinions about what I thought would make for better experiences. In talking with him, we transitioned my role into a product marketing role, which allowed me to get involved in the product lifecycle earlier than when I was in a pure marketing role. Even then, it still wasn't the level of contribution and ownership that I really wanted, so I left and joined Wallaby. ***Matthew*** *What made you want to join Wallaby?* **Jessica** In my product marketing role, I had come to learn about product management, and that role felt more aligned with the level of contribution that I wanted to have in the products that I was working on. I was an early user of Wallaby, and I had met the team at a networking event. Not too long after that, I saw an opening for Wallaby's first product management hire. And here I am. The rest is history. ***Matthew*** *Tell me about the rest of your career. What have been some of your other product experiences or other things you've done that led you back to product? That's a bit of a leading question. I know.* **Jessica** I worked as a product manager for a few years, but then I got very interested in nonprofit work. So, I spent a few years doing volunteer work and was the Executive Vice President for a nonprofit. I feel like I was able to apply a lot of the skills that I built through my time as a product manager to the nonprofit organizations I was working with, particularly on the program development side of things. I thought that I might transition into nonprofit management and leadership long term, but I started to miss the tech space and missed building products that users were using. I came back into tech and the fintech space in a business operations role at Apto Payments. The opportunity seemed like a great fit to blend all of my interests because I got to bring the skills that I had built up with the business operations part of my nonprofit experience, as well as all of the cross-functional collaboration that I think is such a big part of product management. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ***Matthew*** *Your degree is really interesting. I'm not familiar with the phrase “interpersonal communications” as a degree topic. But, in some of these other interviews we've had, people bring up that if they'd known then what they know now they would have gotten psychology degrees to become product leaders. So it probably served you well.* **Jessica** I do believe that’s the case. A lot of what my degree learning was focused on skills for effectively communicating with people in different types of relationships and groups. I think it set the groundwork for being able to work with different types of people, with different personalities, backgrounds, and communication styles. I was talking about Strength Finders with one of our clients, and my results lean really high in interpersonal skills and relationship skills. When we did Strength Finders the first time at Bankrate, I saw all my peers' results, and I felt like mine were almost not good enough. I felt like people had all sorts of other skills that felt so important to being a successful product manager. Over time, though, I realized that there is a big connection to storytelling (which was a big part of interpersonal communications) that has really helped me in product roles. Particularly in the ability to build a narrative and see the through line of all the things we’re building, as well as being able to understand different audiences and tell a compelling story that’s relevant to them. ***Matthew*** *What are some of those skills that you thought you were supposed to have that you think are less important? Or maybe this goes to the technical versus non-technical PM question, but maybe better phrased, what are the skills that you think are most important for a product manager?* **Jessica** I still get self-conscious about being a technical versus non-technical product manager, sometimes, because I don't feel like I'm wildly technical. There's also some perspective that I have to bring in for myself, though, that the level of technical understanding needed often depends on the products you’re working on. For some products, you have to be more technical, or else you won’t be as effective, and so maybe that’s not the best fit for the types of products that I’m working on. At the same time, though, there have been times when I’ve been very envious of people who had more of a data or CS background, who maybe came from engineering and then moved into product, and they just had so much of that background knowledge to pull from. I’ve been fortunate that in the teams and the products that I’ve worked on, I haven’t needed a CS background to be successful. When you have a good technical partner, it’s more about the ability to understand concepts than being expected to be in the details of implementation. I even think for some projects, it’s been an asset not to have a technical background because the relationship between engineering and product can sometimes be tumultuous when you have a product manager who has strong technical opinions, and come too far into implementation. So, being able to know where your limits are while still leaning into the things you are good at to form those good partnerships is what I think ultimately makes product and engineering teams cohesive and successful in delivering the things that are most important to their users. **Matthew** *What, at its core, does product management mean to you? How do you describe your job to people who aren't in the industry?* **Jessica** I often use an analogy of air traffic control or the image of sitting on a fence post and thinking of the different parts of the greater team as being in lanes. Each team - the business team, the sales team, engineering, and design—has their own lane and really deep knowledge about the things happening in their lane, and they’re looking forward to where their areas are going. That’s not to say they can’t see other things around them, but they’re kind of on the ground level in that sense. I see product managers sitting on a fence post, where all of those different lanes come together, with their heads a little bit above where they can scan the horizon and help with coordination so that everybody can be successful and impactful. That way, engineering is building the right things, and we’re delivering things to sales when they need them, and we’re keeping the business informed and taking that exchange of information and knowledge while being able to see a bit more high level than anybody in any of those specific areas might be expected to do. ***Matthew*** *What's one of the biggest challenges that you’ve had as a product manager? What was the story? How did you solve it or overcome it?* **Jessica** I think one of my biggest challenges was my own self-confidence in the beginning. Especially because I felt like I was behind my peers in technical knowledge, and I had heard this narrative of product managers needing to be the "CEO of the product" and have all of these opinions right out of the gate. That’s not accurate, I think, in terms of what product managers need to be doing - particularly new product managers - and so I was getting in my head unnecessarily. I think there's many components to product management, and while we all need to be able to do all of them, I believe that everyone leans into or enjoys one aspect most. There’s a strategic part: thinking about the future and what’s coming down the pipeline and looking through a futuristic lens. There’s a part that is a really tactical day-to-day view, where you’re focused on getting things done that need to be done. And there is also a historical component, focused on data and information gathering about your products, processes, or stakeholders. I think I lean more towards being a historian; I want to understand what’s happening in the product, take the visions of other people, make them happen, and figure out how to make all the parts work. There is still future thinking in that, to be able to take an idea of where you’re trying to get to and figure out what’s in between, but I didn’t have the confidence in that sort of future-thinking. I think I struggled because I took that lack of self-confidence and thought that it meant I was bad at it and, therefore, bad at this job. Luckily, I had a really great manager (Matthew) who recognized this about me and helped build my confidence in that. Those two things coming together allowed me to gain some confidence and build that muscle a bit. It got stronger over time, too. If I could talk to a younger me, I would say that some of this confidence has to come over time; some of it has to come through experience. There are people who come expecting to know how to do everything immediately, but you just can’t. You have to have exposure. ***Matthew*** *I think when we first had conversations about this, you probably weren't even 30 yet, right? I think there's a lot in there that's interesting. I talk a lot about this kind of thing in my strengths-oriented coaching approach; we’re not static as people. You’ve taken Strengths Finders multiple times, and your results have changed, as you know, as you’ve learned new skills. It’s also environmental. I can imagine that if I were you, at Wallaby, and the person who had come up with the idea out of thin air turned to you and said, “What’s next?” It would be pretty hard to answer, because it could feel like a trap, or you could feel like they should know because they were the visionary.* *I think there’s a unique thing going on with founder-led startups. I’ve been doing these interviews with people who have been Chief Product Officers where they were told that they were meant to be the CEO of the product, and that’s a very dangerous position to be in—the CEO is supposed to be the visionary. Execution is the name of the game. What a product manager needs to be good at or do is not always the same thing. There are a lot of product managers, I think, who are lacking the skill you have of looking at what the data tells you. A lot of people build stuff that nobody uses. We don’t talk about that. People will say, “You’re so good at shipping.” And maybe that’s true, but did anybody use it? Did you have an impact, or are you just shipping stuff for the sake of shipping? If code ships in the woods and nobody uses it, did it even matter? I think having some humility about your ability to envision the future is actually really important. So that’s a good one.* *We’ll switch gears a little and think more about the functional stuff: What are some tools that you use every day that you think aspiring PMs should learn or understand? And this could be software methodology, could be an agenda, it could be some other framework, could be any of that stuff.* **Jessica** I would say basic data analysis. Going back to the data point previously made, you have to know how to do basic data analysis. You need to be able to navigate a spreadsheet. It's going to come up in so many different contexts. I think presentation skills, knowing how to build a deck for various audiences, and practicing written communication are wildly important, especially in this role where we’re working with different clients. Even if you're not in a consulting role, you're always going to come into a new company and need to adapt to new people and a new environment. So, while it's important to learn any given task management platform or project management tool, understanding some of the principles of good project management and good task management, like writing good tickets, is really important. You’re always going to live in a project management tool as a PM; that’s part of daily life. I think a wiki or some sort of documentation is great. Not every company is going to have a really formal set of knowledge or processes or tools around knowledge management, but as a PM, you have to find ways to be a good steward of knowledge management. For some teams, that’s Google Docs, even though it shouldn’t be, but even if it is, at least try and be the best person at Google Docs and getting things in there, and at least try to keep your things structured. That way, if you can’t keep the whole company organized, then at least you can be a good example of what that structured documentation looks like so that when people interact with the things that you’re creating, you’re providing a high caliber of documentation. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew** *What are some of the ways that you manage cross-functional work and communication across teams? What are some of your tactics and strategies for ensuring everyone is aligned?* **Jessica** The first one is trying to encourage public communication as much as possible in a way that makes sense within the organization that you're in. It's really easy for one-to-one or one-to-a-few communication to happen, but having a communication platform like Slack or Teams and having public conversations so you’re creating a reference history for new people coming into the conversation. It’s a way for people to catch up, like if an executive or a leader isn’t responding to every conversation and they need to catch up or follow along and see what things are happening. When you’re having conversations in public, it’s easier for people to see things that are going on so that people can be more broadly informed. In general, I think you should be looking for opportunities to tell your product story as much as possible. Whether that’s in cross-functional team meetings, or if you have an all hands, or wherever those places are, know what the narrative of your product is and what you’re focused on; that way, you can keep people aligned and your whole team knows what they’re building toward. I think that as a product manager, you spend every day in that story, so it’s easy to assume that everybody knows it as well as you do. It’s easy to forget that people are not in that same story every day. So, even if it feels like you’re telling the story over and over and over again, that’s how you get people to know what’s happening. I guarantee nobody else hears it as much as you do. Also, finding opportunities to have asynchronous updates that make sense for your team is very helpful. So, if that’s weekly updates about what’s been happening or what your goals are, what’s being delivered, whatever cadence your company uses, just be as clear as possible about what’s coming down your pipeline and how you expect that to impact different parts of the business. ***Matthew*** *What was the most rewarding part of being a product manager for you?* **Jessica** I think the most rewarding part is when the team has an “Aha!” moment with you once you complete a task or ship something. Going back to that fence post analogy, as a product manager, you see all of the different stuff coming down the lanes, you’re out there telling the story of what you’re building and what you’re trying to achieve, and the people hear the story and go along with it. The rewarding part is when things finally come together, and you have a product launch, and the team gets to see and use it for the first time, and they finally get to see how everything came together and feel the impact of their hard work, and you get to see their spark of an, “I get it!” moment. ***Matthew*** *So how has product management changed for you over the last ten years, if you think it has at all? Or do you think it's going to change over the next ten years as a profession?* **Jessica** I think it's partially hard to tell because my role as a product manager has changed so much. It’s so different. I used to work on a single product, but now I work on multiple products that are all in different phases or stages. There’s a commonality for sure, but they also have different needs in some way. I feel like AI is a super common answer. ***Matthew*** *It is common, but it's not inaccurate.* **Jessica** And it doesn’t feel like a, “Go do my job and replace me.” thing, but (and maybe this is a bad thing to say), part of the reason that I thought about moving away from product management is because it can be a very taxing job. You go from talking to so many different types of people that take different types of communication, and you’re doing all different types of tasks. I think it’s a very heavy context-switching job. So, I think one of the things that is challenging for me is to have my brain be in the right mode at the exact time that I need to be able to get a specific type of work or task done. Utilizing AI tools as a partner in helping me get there has really changed my general mental load and energy with the job. Being able to use it to help ideate, to kind of get the juices flowing, or to help me start down a path. It’s not going to do my whole job, but it’s been so impactful for helping me get in the right direction. In addition to all of that, it’s also brought a bunch of efficiency to my day-to-day. ***Matthew*** *Yeah, I mean, it's okay to say AI. Well, that’s all of my questions. Thank you for your time, Jess.* ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Product Talks with Justin Bauer - ProductFTW #38 URL: https://www.productftw.com/productftw-38-product-talks-with-justin-bauer/ Last updated: 2026-05-22T01:57:22.000Z For our fifth post in the [Product Talks](https://www.productftw.com/product-talks/) series, we’re talking to Justin Bauer. I met when Justin founded a startup backed by Mucker Capital, which has backed two of my companies. I think his journey from CEO to product leader is an interesting one. If you want to get advice from Justin, he encourages you to reach out! --- ![Promotional graphic for Product/FTW’s 'Product Talks' featuring photos of Matthew Goldman and Justin Bauer against a gradient background. The tagline reads, 'It’s like a podcast, but you have to read it.'](https://www.productftw.com/content/images/2025/01/Justin-Bauer.png) **Matthew:* Hey Justin, I appreciate you taking the time to do this. Let’s jump in with the classic: who are you, and what are you currently up to?* **Justin:** My name is Justin Bauer. I’m the former Chief Product Officer at Amplitude. I left at the end of last year after spending eight and a half years there. We scaled from a handful of engineers, Series A, and $1 million in revenue to $300 million and went through an IPO. Right now, I’m prioritizing things you don’t prioritize when you’re at a fast-scaling startup—time with family and friends, getting back into shape, and traveling. I convinced my wife to take the summer off as well, and we traveled to Europe with our four-and-a-half-year-old. Now, I’ve started to focus on advising companies. I work with early-to-mid-stage SaaS companies and help them think through how to scale their business, scale their product, and scale their team. It’s been really fun; I’ve been really enjoying it. **Matthew:* That’s awesome. Let’s go back to the beginning. How did you get into product in the first place? What did you study at university, and what was your first product job? What’s the story?* **Justin:** For my undergrad, I went to Carleton College, which is a liberal arts school, and I did not think I’d go into product. While I was there, the computer science program was nearly shut down because they said it was "too vocational." Thank goodness they didn’t because it’s now the number one major at the school. Back then, though, the number one major was economics. I took a bunch of courses in economics and mathematics, and I kind of thought I was going to be a professor. I thought I should get my Ph.D., but before I did that, I decided I should work with other people who have their Ph.D. first. So that’s actually what got me to move out to California; I got an opportunity to work with Daniel McFadden, who won the Nobel Prize in economics in 2000\. He had just started with this firm out in San Francisco. So, that was the first step in the direction of product, just being in the Bay Area. Unsurprisingly, when you’re in the Bay, you get surrounded by a bunch of people working in tech, and so that’s kind of what piqued my interest. But I didn’t really have the skill set to work in tech. Like I said, I was mostly an econometrician. So, I decided to go to business school. In business school, I learned about the Product Management role and thought I might be good at it, so I applied to eight different internships that summer. And I didn’t get any of them. Every single one of them said, “You don’t have any Product Management experience.” And I was like, “Well, yeah, that’s the point.” I did, however, manage to get an internship at Yahoo on their Data Science team. This was back when Yahoo was actually a thing. But that experience just confirmed I didn’t want to just be a Data Scientist. So I did what a lot of people do when they don’t know what they want to do after grad school—I went and worked at a management consulting firm. And, funny enough, McKinsey is actually where I got my first PM job. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:* What is product management at McKinsey, though?* **Justin:** So, I think I was the first-ever product manager at McKinsey. I haven't met anyone else who had built product beforehand. I did the typical consulting stuff while there, and we had this one client that we had built this pricing algorithm for. Six months later, we checked in on them, and they told us that things were going great, but the pricing algorithm that we had built them wasn’t working anymore. We were like, “What do you mean it doesn’t work? It wasn’t supposed to be working after this long, it was supposed to just be a proof of concept.” I built it in Microsoft Access. They told us that they were using it to run their whole business. And the partner was like, “Hmm. That’s interesting. I wonder if we could actually build software to help companies think through how they manage pricing.” And so he raised a couple million dollars from the heads of McKinsey, and we used that to basically pay for me to be a “project manager” and work with a small software agency to actually build pricing software. That became Periscope Pricing, which is still a standalone business unit. That partner eventually became the CEO of that, but I think he’s now gone back to being a full-time partner at McKinsey. But yeah, that was my first experience really building software, and it completely changed my view on how to create impact. Instead of creating PowerPoint slides to try and convince people to try and change how they work, I could . build software that could actually change how they operate and how they work within their business. It’s so much more scalable. Because of that experience at McKinsey, I got placed on a bunch of digital projects. Not surprisingly, all of the partners still wanted to do PowerPoint presentations and whiteboarding, and I was like, “This is not how we should design software. Let’s actually work with customers, build some things, and see if it works.” It was too early for McKinsey to figure that out, but one of the partners of McKinsey who had left to go be the CMO of Sports Authority was like, “I want to start a digital consulting company that does that.” I thought that sounded awesome, so I actually joined him. It was called Axon, and we ended up selling it to Booz. It became Booz Digital, and then they went and started BCG Digital. After that, every other consulting company had to create their own digital arm. So that got me into building software, and around then, I met Will Hsu from Mucker and I told him that I wanted to work at a startup. But he told me that no startup would want to hire me because I would be too expensive and I had no experience. He told me that if I wanted to work for a startup, I should go and start my own company. So, fast forward four years, and I ended up building this app for fun. It was a game, and we figured out that we could potentially monetize it. I ended up joining forces with some friends, and we ended up joining Mucker, which is when we met. **Matthew:* Yeah. I remember talking to you about it. I remember it had to do with sports betting or something. I was so confused. But, it was obviously at the start of a huge trend.* **Justin:** Yeah, we got that timing right. The big learning there, which may not be as relevant for the product audience, is that when you’re in a sin industry like that, you can’t build it in the traditional lean startup way. FanDuel started by raising a couple of million dollars and then went all the way up to 60 million. You could do that because, in those industries, people will throw a lot of money at it, and then all the economics of our business flips on its head. We went from being able to acquire users at $2 and then went to $10 overnight. If you’re in the sin industry, you have to capitalize a lot and change your approach to how you build. **Matthew:* I think also—there’s always timing, right? Like, that was in 2013\. I had started Wallaby in 2012, coming straight out of the financial crisis, and you know, Facebook was figuring things out; that stuff was cheap. Everyone’s acquisition costs were cheap for a while. There was this era of, it’s cheap to do a startup, and now you’ve got AWS coming on the scene doing interesting stuff. Although, Wallaby, for security reasons we couldn’t do AWS because you couldn’t get a PCI cert. And Facebook was cheap, and that was all great. And then all of a sudden, everyone’s piled in, and now everything, including people, is crazy expensive again. I mean, one of the things I used to say to people who think startups are so much cheaper because of Amazon is, “Have you tried to hire a software engineer lately?” There is still a limited supply of some things, and I think you’re right; we talk about this a lot in fintech stuff, that you can’t apply lean to everything. There are certain industries where it doesn’t work. Like, you have higher compliance costs in something like gaming. You can easily burn hundreds of thousands of dollars on lawyers doing certain things.* **Justin:** Exactly. That was definitely a big learning for me that you can’t apply lean to everything. But that experience was great for me because that ended up teaching me a lot about what it takes to build and grow a mobile app. So, after we sold Rivalry, I was having conversations with some analytics companies, including Amplitude, and that was a market that I deeply understood and I hit it off with the CEO. So, as much as it looked like it was a risky bet, I had a lot of confidence in the market and knew what we needed to do to win. I also felt like they had really built the right initial team to win and to build for scale. **Matthew:* That’s such a great story and a really interesting arc. It’s very different from some of the other folks we’ve been talking to, which is what makes this series so fun. Like you said at the beginning you were trying to get a product management internship. How did you know, or what made you want to be a product manager? And what did you think it meant, if you can think back to that early stage of your career?* **Justin:** So, I think I’ve always been a builder. I’ve always loved building things, whether it was building model cars when I was a young child or trying to build businesses when I was eleven or twelve of, you know, stuff like lawn mowing, baseball card business, stuff like that. I even tried to buy some real estate in the middle of rural Iowa. Whatever it is, I’ve always been wired in that way. I didn’t know what I would build, but whatever it was, I always enjoyed that. Even when I joined McKinsey, I actually joined to help build the analytics practice. It’s always been important to me. So, I didn’t know what product management was when I was an undergrad. Like I said, Carleton was so academically oriented. But once I came out to San Francisco and was part of the tech scene, I think that was when I discovered it. I saw it as a part of the triad of builders and certainly was the one that my skillset most lined up with. I had taken a handful of computer science courses, and I know very basic levels of coding because of my statistics background. We had to do some stuff in python, but I’m certainly not a software engineer and actually didn’t know much about the world of design back then. **Matthew:* Nobody knew much about design back then.* **Justin:** Yeah, so it’s kind of interesting because I look back, and I see that I love the research part of product management. It’s probably one of my favorite parts, just talking to customers, talking to users, and for someone in design, that’s a real super skill for them. So, all of those things kind of led me to realize that if software was the thing that I wanted to build, then product management seemed like the right role to at least explore. **Matthew:* So now that you’ve gone from that to both having been a founder and this scaling Chief Product Officer role, if someone comes to you and is 22 and wants to know what product management is and what it actually means, how do you describe it? What does it mean to you?* **Justin:** To me, it’s really the intersection of using technology to deeply solve customers' problems in a way that is financially viable. You’re the intersection of all those points. I think most people, when they think of product management, they just think about the technology piece. They think it’s about getting to come up with cool features. And the reality is, honestly, you shouldn’t be the one coming up with the features. For me, I felt like I have been great at being very clear in stating what the problem is that we’re solving and prioritizing the right problems that, if we solve them, would really drive the business forward, and then setting up environments where we can then collectively figure out the right solutions to actually accomplish that, without dictating those solutions. I think the industry has evolved now; that is how people talk about it. That would be the first thing for me. Therefore, I’d be like, go spend your time figuring out how to get good at doing that, which is a little different than even five years ago, when people would tell aspiring product managers to go take a coding boot camp or go learn how to code. You don’t need to know how to do that. You need to know how to speak to engineers and empathize with them, but honestly, if you are good at understanding customer problems and prioritizing the ones that will drive the business forward, engineers will love working with you. They hate building things that no one uses and don’t make money. So you need to get good at that. **Matthew:* I think that’s right on. I spent a lot of time talking about problem identification as well. You sort of answered one of my next questions which is what advice you would give to new product managers, but maybe I will pick up on your thread about coding bootcamps. There’s often this discussion of how technical you need to be to be a great product manager or what kind of background you need; where do you come down? You said you have a kind of semi-technical background, certainly math oriented. So, how do you think about some of your favorite PMs who’ve worked for you? Or, again, the advice: what would you tell people about needing a technical background or needing a math degree? How do you think about that?* **Justin:** I think it depends on the customer you’re building for. This might be a little bit more B2B oriented. But in my opinion, in B2B, since your job is actually going to be interfacing with those customers, it’s more about how technical they are and not about your ability, like how technical you’d need to be to work with engineering. For example, if you’re building a DevOps product, then you need to understand the DevOps industry. If you’re building an analytics product, you need to understand the analytics industry. And so the fact that I have an analytics background certainly helped me understand the analytics industry, but I had plenty of PMs who came from lots of different backgrounds. I actually found, honestly, that I ended up having to spend more time training people on how to become a PM if they came from an engineering background because they were so solution-oriented. They would allow themselves to get into the weeds in debates that they really shouldn’t versus some of my best PMs, who had a humanities or psychology background. Which, if you think about it, a psychology background is honestly perfect for being a great PM because you understand the user and the customer. That’s your primary job. I can teach you the business fundamentals, but if you’re ingrained in the user, that’s a really great foundation. But, if you are building deep infra for generative AI, you’re probably going to need to understand how the space is evolving, so it requires a little bit more of a technical background. But like I said, it really has to do more with your customers than the product itself, in my opinion. **Matthew:* I agree. And I have similar experiences. So, maybe with this is the next set of questions, we’ll lean on your recent experiences at Amplitude, but you can drive from anywhere. What was one of your biggest challenges as a product leader? This is the interview question. What’s something that sticks out? Like, this was super hard, but we found a solution. It could be prioritization, it could be team dynamics, whatever. Anything is fair game.* **Justin:** I think the hardest thing for me was probably when we went multi-product. I think of a couple of key pivot points in Amplitude’s history. The first one is when we joined, and we figured out the ICP, to focus on product management. The second was how we figured out how to go after enterprise, and then the third was when we went multi-product. The multi-product one was very hard. All of them had their difficulties, but I think I underestimated how difficult multi-product was going to be because of how much it changed everything. It’s not just figuring out a second or a third product to build, which is hard enough. It completely shifts the go-to-market team and how they think about the world. So, a lot of the learnings I had there were around me not spending enough time understanding our go-to-market, and how it worked at that stage, to then think about how we were going to sell through these products when their incentive structure was not aligned at all, because they’re just trying to hit a revenue target. I can give you a specific example. We built this experimentation product, which has done incredibly well. Initially, when we were building it, we thought we were going to target large enterprises. Then I thought we needed to pivot because they weren’t moving fast enough, so we went after mid-market. That pivot was right, and we ended up seeing a lot of traction – something like 10 or 15 companies that were signing LOIs for us. We thought, “Great, this is awesome!” and even moved up the launch date because there was so much interest. So I handed it over to the team that does all of the sales training, and we helped them out and I just assumed that sales training would go great. We had the launch, and then a bunch of customers started asking about us, and we realized that we didn’t train the right people. We trained the salespeople, but salespeople at that time didn’t handle expansion on mid-market; it was actually customer success that did that. But we only trained the sales team. So, the CS team was not ready, and it was a disaster. Had we not had so much proof that this was going to be a successful product, there’s a chance that if you just looked at how it did in its first quarter, and that was the only thing you saw, you probably would have thought we should kill the product. But the reality was we ended up figuring it out. So that was a big learning point for me. **Matthew:* That’s an interesting point at the end, knowing when to pull the plug and when not to. How do you balance this lean startup, rapid change, and pivoting while growing with the conviction that there may just be issues with the execution, messaging, or go-to-market strategy? I think that’s such an amazing question.* **Justin:** So, one of the things that I do for that, is I try to minimize the number of handoffs that could risk the execution. So, for example, I learned that I’m going to have the Head of Product for any of these new products that we build sell the first 10 or 15 deals themselves. I actually learned this through the experiment example because I was able to do it. The Head of Revenue told me that our product wasn’t selling that well, and I didn’t understand why because we had so many LOIs. So when we launched our next product (CDP), I did the same thing; I had the Head of Product go out and do all of the initial deals. And that’s what gave me confidence that there was demand for this. Obviously, that wasn’t scalable, and it was a very hard quarter for him because he had to do both product and sales. But then in the next quarter, when we did do the handoff, we went from signing 15 customers to signing 3 customers. It just speaks to how hard a sales job is, Amplitude had an amazing sales team. Since we had signed so many deals ourselves, I knew we had fit, and I knew we had the right solution and that it was an execution thing. So then, that gave us the time to figure out the execution side versus if I had just built something with a couple of design partners and handed it over the fence, and then we only sold three in the first 6 months. Then, it becomes a fight between me and the Head of Revenue. I never want to be in a position where I feel like I’m advocating for what my hat naturally advocates for because then everyone would just assume that I’m advocating for it because I’m the Head of Product and I’ve spent so much time on it. I actually want to have an unbiased view. So, that’s one of the ways that I think about how I can have that. That actually helped us shut down another product, where the Head of Product only got us three customers, and we couldn’t get any more after that. If you can’t sell it, as the founder of this product, I guarantee you that an AE will not be able to do it. **Matthew:* I think that’s a really good lesson. We talk to zero-to-one startups about founder-led sales, and also how to scale that same methodology further along. It adds to the ability of the product leader to get rapid feedback on the nuances or tweaks that have to happen to get to a real fit. I think there’s a tendency for product managers to think that they’re just building software, but Product is a much more expansive job. To me, a true product manager understands the go-to-market and channel education, customer success, and operations and owns the whole thing. You need to know how all of the things come together because you can build cool software, but if you can’t support it, then it doesn’t exist.* **Justin:** Exactly. We really encouraged PM as GM mentality, I think PMs need to adopt it. You always hear, “The PM is the CEO,” and the reality is, it’s not; you’re not everyone’s boss. But the mentality of being a GM, I think, is the right mentality. I think we will see that a lot of great GMs are going to come from PM backgrounds. Traditionally, GMs have come from sales backgrounds. I think in B2B, you’ll see a lot more coming from the product management background because they can take a more holistic view. **Matthew:* Did your PMs own the P&L?* **Justin:** No. They didn’t technically own the P&L, but when I think about the new products, that was all we talked about was the number of customers and the amount of revenue. I think you actually need to think very carefully about those targets on product people. I actually don’t recommend ARR being the right target when you launch a second or third product in the very beginning because it’s a lot easier when you have an existing customer base to do bespoke software consulting-y stuff to close a couple big deals, and it doesn’t scale. That was the challenge with the prior example we shut down, the PM was able to get three deals done, it was actually a lot of ARR. All three of them were multiple $100k ARR deals, and we were like, “This is great!” But it was too bespoke to those customers, it didn’t scale and we couldn’t get any additional customers. So that’s when I realized that the number of customers was the right thing at the beginning. Then, eventually, you get it to revenue. **Matthew:* I mean, I don’t think I want to go down this rabbit hole right now, but that’s a whole other discussion about the challenge in early SaaS product, of customization and the best practice or best way to do things. I spent some time in consulting as well at Deloitte. They did a lot of custom SAP implementations, and we were constantly adjusting how the software worked to try and fit someone’s business process, which was always a disaster, frankly, and cost absurd amounts of money. The reality is that you should build a best practice piece of software and tell business people to adjust how they work, which nobody really likes, but people are way more flexible. I’ve seen a lot of companies where they have a unique feature of some sort for every customer, and it just becomes completely unsustainable and unscalable every time. Then, suddenly, you can’t build new things anymore, and you turn into a giant tech debt management shop, and it’s no fun.* **Justin:** I agree. For Amplitude, that was our MO. We were building for the future of what it looks like to use data to build products. But I will say, the downside of that is that if you don’t have a leader at that organization who knows how to drive that change management in the company, your software will fail. To pair with that, I think we were late to the game in building out the services side for when we went after enterprise. It worked great when we were just focused on tech because everything was happening in tech. We saw early wins with companies like Ford and Burger King, who had leaders come in from Uber or Microsoft and changed the way they operated. Amplitude took off, and they became multi-million dollar customers. But then you look at the exact same industry, and we had customers like Honda, who churned out after being a $50k customer for two years. The software was exactly the same; it had everything to do with the fact that, for whatever reason, Honda just didn’t have the change management program in place. So, at some scale, you need to take control of that as a software business and either build it yourself or partner with a bunch of service organizations that can drive that change. **Matthew:* Yeah. All right, I’m going to shift gears up a little bit. I have one last really interesting question for you before we get into some lightning-round-type questions. So, one of the biggest challenges is being the Head of Product at a founder-led company and figuring out the dynamics of balancing who is responsible for the vision and roadmap decisions. It’s tricky when founders have, and you know this because you have been one yourself, kind of have a special authority. How do you think about the role of a CPO in a startup where you have that unique dynamic of having a CEO who might think, “I’m the Head of Product, really. I make the decisions.” Maybe you haven’t had this experience, or maybe you’ve experienced it somewhere in an older, more professional organization.* **Justin:** I think you have to be really clear on what everyone’s roles and responsibilities are. For the CEO, I think about the company vision, like what kind of company we want to build and the company strategy. My mental model was that the CEO and I kind of shared the product vision, but he’s coming at it more from a company strategy like, “Where do I think this industry is going?” And I’m thinking of it more of like, “ What are the core problems and underlying trends within technology that I think will allow that to happen?” But the product vision, I think, has to be a melding of the two. I don’t think it works if you have a CEO who completely owns it and a PM who just executes. I also don’t think it works the other way where it’s a PM who has a different vision than the CEO; that won’t work either. That’s kind of the messy middle, but it should be messy. I think it’s a superpower when you get to have multiple brains that are really forming that vision. On the execution side, I think that really does need to sit in the world of the Head of Product. But that doesn’t mean you should shut your CEO out. You want them to be part of that, but you’re having conversations around product strategy with them. At the end of the day, as a Head of Product, your job is to articulate the product strategy and then figure out who is best to execute it. I think another piece of advice I would offer, and maybe this is a little bit more founder-specific, but you need to design yourself around the intricacies of the founder. Spenser (CEO and Co-founder of Amplitude) is incredible at finding out what the most important thing we need to be focused on right now that will drive us forward over the next 6-12 months. Once he figured out what that one thing was, it was going to get fixed. He would drive it with an urgency that you have never seen before. And so, every once in a while, that was in your area. And I saw execs that failed when they took it personally and tried to manage him. For me, when it was in my area, I just recognized that, “Yeah this isn’t great, and it is super important.” I almost thought about him as being a super IC PM. I remember when we were working on a new pricing plan, he told me that our first-time user experience was just not where it needed to be. And I completely agreed. We hadn’t been focused on it, we’d been focused on enterprise and multi-product. So, the first step was to acknowledge it. And then he wanted it fixed right away. So I paired him up with one of my top PMs, and then I encouraged him to just do what I would have done otherwise, which would be to spend a lot of time with the team to fix it. It worked perfectly because I didn’t have to be in on any of the meetings, and then in our 1:1s, I would check in on how things were going. I was coaching the PM he was working with on the side, but that was the right way, in my opinion, to work in that kind of environment. When Paul Graham wrote the founder mode paper I kind of chuckled, because to me that was theway Spenser always operated. You may not have a founder that’s like that, but the point is that you need to figure out how they operate, and then you kind of have to mold yourself to them. **Matthew:* That’s great, thank you. All right, so you’re not running a product org today, but let's say you are starting somewhere new, and you had to. If you were designing from the ground up, how are you building software? Like, what methodologies are you using, or are you doing your own thing? What are your favorite tools? Imagine you get to choose your tooling, your ticketing, your wiki, and everything like that. What are you choosing?* **Justin:** Good question. It’s funny because I was always very open to allowing teams to try a lot of different tools, and that was actually something I’ve learned along the way, that once you get to a certain size, you eventually have to standardize. I’d probably try out Linear because I haven’t used it yet, and I’ve heard people like it. Honestly, tooling matters less to me than what the core fundamental principles of building product are. The first is that customers are a part of the team. The first thing I would do is decide that 20% of every PM's time should be spent talking to customers. A lot of people hear that, and they’re kind of shocked because it’s a whole day a week spent talking to customers. I would do a quick diagnostic on how often the PMs are talking to customers, and I bet it would be not enough. Then, I would focus on building all the infrastructure that makes doing that possible. Part of the thing that makes it happen is that you have to actually make it easy for PMs to talk to customers because if they spend all their time figuring out how to get to customers, they won’t have that many conversations. So, that would probably be the first thing that I would focus on. The second thing I’d do is probably, depending on the stage of the company, focus on taking whatever the batch size (meaning how often we build things) is, and I would probably cut it in half. If right now we are doing things on a quarterly basis, I would see if we could start measuring things on a six-week basis. I’ve just found that work fits to the batch size of planning, and so if you want more velocity, you just reduce the batch size. So, if that were a problem, then I would probably focus on that. My other principle is to iterate to learn. So, let’s reduce the batch size and figure out how to learn things a lot faster. The third thing would probably be that I would look at where the idea is coming from for all of the features we’re building. At a lot of organizations, all of the ideas are coming from PMs, and I don’t like that. I would lean into how I could get designers and engineers to actually be able to come forward and propose their solutions. There’s a lot of different things you can change there. Like, just have people write a one-pager instead of PRDs because an engineer or a designer won’t want to sit down and write a whole document. If you do that, then you’re only going to have PMs that are actually getting it done. I can go into details with those things, but those would be at least a couple of the areas that I would probably dig into if I were joining a new organization. **Matthew:* Awesome! Well, we’re out of time; that’s what happens. This was a lot of fun. Thanks again for taking the time.* **Justin:** Of course, this was fun. Thanks! ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Prioritization at Startups - ProductFTW #37 URL: https://www.productftw.com/prioritization-at-startups-the-reality-no-one-talks-about/ Last updated: 2026-05-10T23:40:22.000Z Picture this: You're leading a startup's six-person dev team. Your CEO is laser-focused on the new product you're building, but a potential enterprise customer is dangling a massive contract if you'll just add one feature to your existing product. Your runway clock is ticking. Welcome to prioritization at a startup. ![A two-panel "Drake Hotline Bling" meme. In the top panel, Drake is turning away with a hand gesture of rejection, next to the words "Kano, MoSCoW, Rice," referencing prioritization frameworks. In the bottom panel, Drake is smiling approvingly and pointing, next to the words "Bullet points," suggesting a preference for simpler prioritization formats over more complex ones.](https://www.productftw.com/content/images/2024/12/drake.jpg) Heavy prioritization process? Not like us ## **The Startup Reality** Every product management book will tell you to use frameworks like RICE or MoSCoW to bring order to your backlog through careful scoring and evaluation. They promise to make prioritization objective and scientific. The reality? At [Perigon](https://www.goperigon.com/?ref=productftw.com), we're building an entirely new product while maintaining our news API platform. Recently, we faced the decision of whether to pause development on our new app to build a feature for a potential enterprise customer. A traditional framework would have said to stay focused on the core roadmap. Instead, we saw an opportunity to land a major contract with a feature we could eventually use across our product line. This situation demonstrates why traditional prioritization frameworks miss the mark in startup land: Everything changes too fast. No framework could have predicted or properly weighted that enterprise opportunity – we had to react based on business instincts and quick analysis. When the contract was on the table, we needed to make a call quickly or risk losing the deal entirely. You're optimizing for survival. At my previous role as a product lead at Red Ventures, we had established products and could plan quarters ahead. At a startup? We have six developers and limited runway. We need to focus on what moves the needle now, whether that's landing customers or learning what doesn't work. At a startup, your team is too small for heavy processes. Our entire company fits in one Zoom screen. We don't need complex scoring systems when we can just turn around and talk to each other. The overhead of maintaining detailed frameworks would actually slow us down. At Perigon, we can have a priority discussion, make a decision, and start executing in the time it would take just to update a prioritization spreadsheet at a larger company. I can hear the objections: "But without frameworks, how do you make objective decisions? Won't everything become chaos?" Here's the truth: startup prioritization isn't about finding the perfect framework. It's about making calculated bets while keeping your options open. Sometimes, that means pausing your primary initiative to seize an opportunity. Your priorities will change. Your assumptions will be wrong. The key is building a system that embraces this reality instead of fighting it. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **A Different Approach** After trying various methods at Perigon, we've landed on something deceptively simple: maintain a clear, prioritized list of the 5 most important projects that move us toward our vision. No elaborate scoring systems. No complex roadmaps. Just brutal clarity about what matters most right now. Here's what our priority list might look like: 1. New product development: Core feature X 2. Enterprise client feature for current product 3. Infrastructure upgrade for scale 4. Analytics dashboard improvements 5. Search performance optimization "Such a short list?" you might ask. "What about everything else that needs to get done?" This is where the reality of startup execution comes in. Having a short priority list doesn't mean only working on one thing at a time. Even with six developers, forcing everyone to work on the same project actually slows you down. Different features require different expertise, and developers end up blocking each other or working on things they're not best suited for. Instead, we use our priority list to guide how we deploy our team's capabilities. We typically have 3-4 developers on our highest priority, while others push forward on the next most important projects that match their expertise. About 20% of our capacity goes to maintenance work - bugs, production support, technical debt, and smaller improvements. Here's where being small is actually an advantage: we can reassess and reprioritize at any time. When that enterprise opportunity came up, we didn't need a two-week roadmap review with multiple stakeholders. We had a quick discussion about trade-offs, made the call, and shifted two developers to the new feature while maintaining momentum on our main product development. The entire decision process took one 15-minute meeting, not a month of planning. This isn't about juggling multiple priorities—it's about being realistic about how work actually gets done in a startup. Your priority list keeps everyone aligned on what matters most, while your small team size lets you adapt quickly as circumstances change. There is no bureaucracy, no complex change management processes—just quick, informed decisions and rapid execution. At a startup, your biggest risk isn't making the wrong choice—it's taking too long to make any choice at all. ## **When This Breaks** Like everything in startups, this approach isn't perfect. Product veterans like Marty Cagan would likely argue it's too tactical—where's the deep product discovery? What about quarterly OKR planning and detailed outcome metrics? They're not wrong, but they're solving different problems than early-stage startups face. Still, you need to recognize when this lightweight approach starts breaking down. Here are the warning signs we've hit at Perigon: Dependencies become blockers. We recently faced this when our new product development started requiring changes to our core API. Suddenly, our "parallel tracks" started crashing into each other. Two developers who were working on the new product needed API changes that would impact three other projects. Our usual quick priority discussions turned into technical debt debates. The solution wasn't to add more processes—it was to temporarily compress our priority list. We moved the API work to the top spot and paused features that would require API changes. Not elegant, but effective. Another red flag is when your "20% maintenance capacity" starts routinely stretching to 40% or 50%. This happened to us when we landed several enterprise customers in quick succession. Each had its own small requirements and bug reports. Valid needs, but they started eating into our core development time. We had to make a hard choice: either expand the maintenance team or risk slowing down key projects. We chose the former, knowing it would impact our velocity on the new product. You'll also notice strain when your team grows. Our approach worked smoothly with six developers. At ten or twelve? You'll start needing more coordination. More importantly, you'll have team members who haven't been around since the beginning and don't have the context for quick decision-making. That's when you might need to start incorporating some of those traditional product management practices—just enough to maintain alignment without losing agility. The key isn't to avoid these breaking points—they're inevitable. Your job is to recognize them early and adapt before they create real problems. Sometimes, that means temporarily constraining your priorities even further. Other times, it means adding just enough process to keep things running smoothly. But always err on the side of doing too little rather than too much. You can always add process later; it's much harder to remove it. ## **Closing** Most of us at startups have read the same product management books and studied the well-known frameworks. We've been told we need rigorous processes, dedicated product teams, and months of discovery. And while that advice isn't wrong, it's solving different problems than most early-stage startups face. The reality of startup prioritization is messier—and simpler—than all that. Keep your priority list short and clear. Let your team work in parallel when it makes sense. Move fast when opportunities arise. Be ready to adapt when the system starts showing strain. Sure, you might occasionally wish you had made a different call, but that's better than being the startup that had a perfect prioritization framework and perfectly organized backlogs... and ran out of runway before finding product-market fit. Remember: At a startup, your biggest risk isn't making the wrong choice—it's taking too long to make any choice at all. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. # ### Bug Handling - ProductFTW #36 URL: https://www.productftw.com/productftw-36-bug-handling/ Last updated: 2026-05-22T02:26:29.000Z ![Digital illustration of a conceptual software program represented by overlapping wires in muted gray, beige, and soft blue tones, with a central computer window displaying abstract lines of code.](https://www.productftw.com/content/images/2024/12/DALL-E-2024-12-11-11.21.05---A-digital-illustration-of-a-conceptual-software-program-represented-by-overlapping-wires-in-muted-colors-like-gray--beige--and-soft-blue.-In-the-cente.webp) The image generator kept wanting to add butterflies to this. Call it a bug. Software has bugs. OK, most software. There are organizations focused on shipping 100% quality software that powers things like rockets to space, but for most organizations, speed wins out over perfection, and software bugs are introduced in development, missed in quality assurance and user acceptance testing, and shipped to users. Finding and fixing bugs can be a big challenge. In this article, we’ll cover some key factors in obtaining good bug reports and how product managers can triage these bugs. ## Ideal Bug Reports A product management joke: > What’s an ideal bug report? > **None.** OK, but after that? An ideal bug report includes key information such as: 1. What is going wrong (e.g., what is the expected vs. actual behavior)? 2. Where is this happening (e.g., which environment (test, stage, production), which device (web, iPhone), which client (e.g., native app, web browser, version), and all the other details you may need. 3. Why is it important to fix it (e.g., what are the repercussions)? 4. When is this happening (e.g., a specific time of day or following a specific event)? 5. How do I replicate it? In our modern computing environment, we can also obtain more details from users by asking them for screenshots, screen recordings, and other evidence of their behavior. Let’s walk through an example. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. I use an app to manage fresh farm food deliveries to my house. (The food is great; the app is not.) They have a feature in which you can select certain foods to automatically be ordered each week, such as eggs. If you want more or less of something each week, you can edit that item in your cart, which opens a modal asking if you want to make this change this week only or permanently. All in, it’s a good feature. However, on mobile, when you reduce the count of the item and try to select this week only, the entire app crashes. This does not happen on web. So, what should this look like? **Bug Report: Changes to Weekly Food Order Quantity Not Saving Correctly** **What is going wrong?** When editing the quantity of a recurring food item (e.g., eggs) in the app, the "This Week Only" or "Permanently" options appear in a modal. However, selecting either option does not save the change correctly. The app crashes, and the order is reverted to the original quantity upon review. **Expected Behavior:** The app should save the updated quantity based on the selected option ("This Week Only" or "Permanently"). **Actual Behavior:** The app crashes, the updated quantity is not saved, and the original quantity remains in the order, regardless of the selected option. **Where is this happening?** - **Environment:** Production - **Device:** iPhone 14 - **Operating System:** iOS 17.1 - **App Version:** 3.2.5 - **Network:** Wi-Fi and cellular tested **When is this happening?** - Happens consistently every time I attempt to modify the quantity of a recurring food item. - Observed between 6:00 PM and 8:00 PM (PST) on December 9, 2024. **Steps to Reproduce:** 1. Open the app and log in to your account. 2. Navigate to the "Recurring Orders" section. 3. Select an item with a recurring weekly order (e.g., eggs). 4. Tap the "Edit" button for the item. 5. Adjust the quantity (e.g., from 1 dozen to 2 dozen). 6. Select the option "This Week Only" or "Permanently" in the modal. 7. Review the order summary. **Result:** The app crashes immediately, and the item quantity remains unchanged in the summary when you reopen. **Impact:** This bug prevents users from accurately adjusting their recurring orders, potentially leading to incorrect deliveries. **Additional Notes:** - The issue persists even after reinstalling the app. - Confirmed the issue on multiple devices and networks. I could also include a screen recording or screenshot here to further my report. ## How to Get Good Reports I love having a form to get reports. This can be something built into to your existing project tool (e.g., a template), or a tool like a Typeform where you can walk people through the process and then use an API to deliver it to the bug system or a spreadsheet, etc. ![This image shows a bug report template within an issue-tracking tool. At the top, there is a placeholder title labeled “[BUG]” to represent the bug name or identifier. Below that, there are sections labeled “Description” to describe the issue, “Impact” to explain why the issue should be fixed, “Replication Steps” to outline the steps to reproduce the bug, “Expected Behavior” to describe how the system should work, and “Actual Behavior” to describe how the system is currently functioning. The template also includes a “Device Information” section for details such as environment, device, operating system and version, and network, followed by an “Additional Notes” section for any other relevant information. At the bottom, there are options to assign labels, priorities, and assignees, as well as buttons to save the issue as a draft or create it.](https://www.productftw.com/content/images/2024/12/PFTW-Bug-Template-1.png) Our bug template in Linear ## How to Triage The hardest part of bug reports after you verify may be triage. How do you know if a bug occurs frequently, and what its impact is? The answer is in data. Ideally, your app has instrumentation that allows you to see errors or crashes. This can show you how frequently this is happening. You can also look at the impact when it does occur. Are you losing a sale? Falling out of compliance? Or merely annoying a user? Triaging bug reports is all about balancing impact and urgency. Start by evaluating the bug’s severity: Does it crash the app? Does it block a critical workflow? Or is it something minor, like a misaligned button? Then, consider the bug’s priority in the context of your goals—does it affect a high-profile feature, a key customer, or an upcoming release? Triage isn’t just about fixing the loudest complaint; it’s about aligning your decisions with the bigger picture. High-severity issues that impact many users should get immediate attention, but sometimes a low-severity bug tied to a VIP customer or a strategic initiative might take precedence. By focusing on these factors, you can ensure your triage process is purposeful and that your team is focused on delivering real value. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Product Talks with Greg - ProductFTW #35 URL: https://www.productftw.com/productftw-35-product-talks-with-greg/ Last updated: 2026-05-22T01:50:26.000Z For our fourth post in the Product Talks series, we chatted with Greg Isaacs. I'm sure you'll be surprised to read that Greg is another former AT&T Interactive colleague of mine. He's been CPO at multiple companies and brings a wealth of knowledge, especially on the topic of hiring product roles through many of his roles but particularly through the work he's currently doing with Criteria Corp. ![Promotional graphic for Product/FTW’s 'Product Talks' featuring photos of Matthew Goldman and Greg Isaacs against a gradient background. The tagline reads, 'It’s like a podcast, but you have to read it.'](https://www.productftw.com/content/images/2024/11/Greg-Isaacs.png) **Greg:** All right, let's roll! Thank you for the opportunity, by the way. ***Matthew:*** *Yeah, of course! So, let's start with what your job is today. Where do you work, and what do you do?* **Greg:** I'm the Chief Product Officer at a company called Criteria Corp, which has been in existence for 16 years. The company's mission is to help companies of all sizes find and develop better talent. I think we’re unique because there's this industry that I didn't know much about around psychometrics. These are commonly known as assessments that will measure someone's cognitive ability, personality, emotional intelligence, and soft and hard skills. But really what we do is we give clients, who range from small businesses to large enterprises, confidence that they are making the right hire and then ultimately helping those people be successful. Prior to working at Criteria and being the company’s first Chief Product Officer, I worked at ZipRecruiter for a number of years running International Operations. I learned a lot about talent acquisition while I was there, so that’s kind of what introduced me to this field. The thing that always struck me about talent acquisition is that—we've been in a lot of organizations where technology has had a fundamental impact. So think about Salesforce and what it did and the idea of a CRM, marketing automation, financial systems, et cetera. But HR, and specifically talent acquisition, didn't really leverage data as much as it could have. And when I say data, I mean things that help with understanding what makes a person successful: their cognitive ability, their personality, and how those things align with the role that they're looking to be hired for. In a nutshell, we give a data-driven approach that gives clients confidence they're hiring the right person but also makes sure that it doesn't create unintended bias. It's a really fascinating field, I've learned so much. I get to work with a lot of brilliant PhDs, and so, for me, it really melds the art and the science of what I think makes Product Management great. So I’m really excited about that. I've hit year four, which is exciting. We've executed our product vision pretty consistently, and I would have imagined at year four, I would think that it was time to move on to the next opportunity because we'd done everything we wanted to do. But I have to say, I'm even more excited now than I was when I started because what AI has done to our business and to the product that we can build has been pretty game-changing. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ***Matthew:*** *I bet. That's awesome. So you mentioned ZipRecruiter, but what's the longer arc? How did you get here? This is not your first Chief Product Officer role, so what’s the path to getting up to this point that you took?* **Greg:** I had kind of an interesting path. I've always just generally tried to follow two rules when looking for job opportunities. I didn't have a great vision of becoming a Chief Product Officer or even getting into Product—I actually didn't know what it was. But in general, I tend to follow or try to work with really smart people; people I admire and know are different in a really positive way. When I look back to earlier in my career, when I started working at eBay, I just knew someone there, and he hired me to work for him. Working there opened my eyes to so many different things. For example, the idea of a marketplace and what marketplaces are, how they tick, and how they work and the dynamics of them, or the idea of a platform and what can be built on top of it. So again, the first thing for me is I generally try to work with really smart people. And the second rule is, is it something that I can understand that I feel like, on day one, I could add value? Does it make sense to me? Can I explain it to my friends, my wife or family, or even my kids? I found opportunities where I had a tough time explaining it to them, or they didn't understand it, and I didn't get excited about it. But when they understood it, and they're like, “Oh, that's cool.” I got excited by that. With Product, as I found out later, it’s this really unique mix of left brain/right brain and also, strategic and tactical. For me, the context-switching in any given day is really exhilarating. I could talk to a Fortune 100 Company about some of their challenges. And then the next meeting could be about making small changes to our design. Like, “Have we thought about modifying the UI/UX a little bit?” It just really gets me pumped. But I would say that the arc was not, to be honest, one where I knew I wanted to be a Chief Product Officer. I knew what I liked, and I just sort of circuitously found it. And now that I've done a couple of different Chief Product Officer roles, and I've also done Chief Marketing Officer roles, Product for me is the 1a; it's the thing I really love, and hopefully, I get to continue to do it. ***Matthew:*** *Yeah, you're only the third person I've interviewed, but no one I’ve talked to knew that this was what they wanted to do. I'm not even sure when the title of Chief Product Officer first appeared. The first time I heard it was probably six or seven years ago.* **Greg:** The first time I'd ever heard about the role was when I was at eBay. There were a few people who worked at world-class tech organizations like Microsoft, and so they were Product Managers. I feel like at eBay we did have a Chief Product Officer, so that was the first time I heard it. But yeah, unless you're in tech, nobody really knows what it is. Even people ask me what I do, and I tell them I’m a Chief Product Officer, they’re like, “So what does that mean exactly?” The way I explain it is I get to work with business people who want things. They could be salespeople, for example, could be marketing people. And I also get to work with technology people who can build that something, and I try and find the commonality and get those things done. Obviously, I don't want to diminish what we do by saying we're not business people because I think we are. And in some cases Product people are quite technical. But that's the way I describe it to my kids or to people who aren’t really familiar with tech. And generally, I just show them something. I’m like, “You see this thing on my phone or this thing on my computer? My job is to figure out if we should build it and then, candidly, make money off of it.” **Matthew:** *Well, that kind of leads to one of my questions, which is, what does Product Management mean to you? So that was kind of how you explain the role to someone, but maybe take it a step further. What do you think it really means, or what's its role in the business?* **Greg:** I've actually put together a presentation about what a product manager does at the last few companies I’ve been at because, at least at the organizations that I get attracted to, they haven’t had a product function. And what I like to describe it as is being the closest thing to a CEO at a company without actually being the CEO. Because, you need to be multidisciplined in your capabilities as a PM. So you need to understand the business dynamics, the competitive landscape, monetization, user behaviors, and you need to understand your clients intimately - there are a lot of facets you need to understand. Which doesn't mean you need to do them all perfectly. But for me, at least, the way I like to run product teams is that all product people should have a fundamental understanding of many of those things that I described. So, when I look to hire people, and I interview them, I tell them what the product role in an organization is. I say, “You are the GM or the CEO of your feature or your product line.” The reason I convey it like that is because sometimes product is about shipping the widgets, and then your job is done. To me, that's only the beginning. It’s figuring out what you’re building, shipping it, and then figuring out how to make it successful. The other thing about product is that it’s not just about the capabilities of a product manager; it is also the mindset. The deck I put together, which I alluded to earlier, was really about, what does that mean? What is a good product manager? Well, they're intellectually curious, in my view. They are really data-driven, but they also can understand that they need to make decisions with imperfect information. They generally try to move quickly. They're decisive. I like to do this during interviews because I want the people that I'm interviewing to hear my vision for the role, at least at the organizations that I'm running, and see how they react. Does that excite them? More often than not, if they're not excited by it, it means they may not be the right individual for the product organization that I'm trying to run. I've been in a few different jobs, and so I think I've seen what works well and what doesn't. From there you just try and take the things that work well and do more of them, and you take the things that don’t work well and try to eliminate them or at least put them in a box, so to speak. ***Matthew:*** *Yeah. I was thinking about the days when we worked together at AT&T Interactive, we had this concept of these different types of product managers. I was a business manager, which meant I had a P&L, and we also had PMs, and there was a lot of frustrating back and forth about who was technical or not technical, which used to drive me nuts. So to your point about the product manager being like a GM and having some ownership of a product, not just over delivery but over its lifecycle - can you expand on that thought? And also a bit about how you think about technical backgrounds versus non-technical backgrounds, and what maybe some of the distinctions in your mind, that you make about ultra technical PMs?* **Greg:** At the end of the day, I think having a technical background is incredibly important for a product manager role. Maybe I'm biased because I don't have a true technical background; I don't have a computer science degree. But I don’t think it’s a requirement to be a successful product manager. I think the other things I mentioned earlier, like having the right personality for the role, and a few things I didn’t mention, like being patient and collaborative while still being able to reach a consensus and willing to take calculated risks, are important. I think being technical is helpful because you can always think about if there’s a better way to do things and speak with credibility on that option. But candidly, I've been in this world for 20+ years. I ran a developer program at eBay and worked with technical people all day long. I think if you're honest, you don't know what you don't know. You learn to seek counsel and advice, and you develop a pretty good BS meter when you know someone's not being completely intellectually honest with you, but these skills come with time. As much as I'd love to be technical in terms of being able to code, I think if you've been around enough organizations, you understand how technology works. You may not know down to the bit level, but you have a really good understanding of what solid architecture is, how we build things, and how you structure teams. Ultimately, I think it's important because I've run technology organizations, and I personally prefer to have a really great partner in a CTO. I have been in organizations where I've seen technology teams work really well, whether I was running them or someone else was. I think I know what to look for in a great partner. So that’s a long way of saying; for me, I don't feel like it's a requirement to be technical. It certainly helps, but I wouldn't sacrifice being technical for not being good at those other things I mentioned earlier. **Matthew:** *That makes sense—and I agree. It's funny because I have a technical background; I used to write code and stuff, even though I don’t have a CS degree. So, when people used to ask me this, I would say that, yeah, you should be technical. But then I looked back at all my favorite PMs who have ever worked for me, and none of them are technical. So I was like, okay, well, forget that rule.* **Greg:** I tried learning Ruby a bit when I was at AT&T, and I thought it was cool. But, at the end of the day, it wasn't going to help. The amount of time I would have had to spend to become really technically proficient and to become a real coder just wasn't worth it because, at that point, I'd be sacrificing my time on other things. Since we’ve been mentioning AT&T, I think it would be worth discussing something that I learned and keep going back to. One of the most valuable lessons I learned at AT&T was not to assume and to go and actually talk to customers. So, if you remember back when we started at AT&T, or I guess yellowpages.com at the time, I went on a few sales calls with one of the local salespeople, and I started to sit in meetings with their clients or on their sales calls, and one was with an industrial scale company, which I didn't even know what that was. We talked about algorithms, cost per click, being performance-based, and all these different metrics, and I was watching how the rep sold and how the clients responded. Like, “ If you spend this, you get your ad here.” It was just so eye-opening to see, like, we're tech guys, and we're thinking about the world this way. But the client base we're selling to, or the go-to-market team and the way they sell, it was so different. It was just so eye-opening to me. And so the lesson is, I don't assume anything anymore; I will talk to clients. When I first joined my current company, I spoke to 50 clients just to hear about their pain. And that, for me, was a really valuable lesson. The other lesson was just about how you talk to go-to-market teams; in this case, I’m referring to revenue and understanding them and their pain points. Their pain points are so fundamental, you really need to understand how they sell, the friction they run into, the challenges, and what they're selling. In my opinion, from a product perspective, you can build the most wonderful product you can, but if they can't sell it right or they're not convinced they can sell it, then it often doesn't result in success. And so those were two painful lessons to learn, but ones that I've taken with me in pretty much every other role I've had. ***Matthew:*** *Yeah, I think that's extremely well put. And it goes also to your point about PMs and their responsibilities. PMs are responsible for the delivery of software, but that's not all they're responsible for. If there isn't a channel strategy or clear reasons to buy, it's not going to work. And I agree, I thought that was a really interesting part of AT&T. I did a ton of sales calls as well and flew out to different regions and went to the call centers, and I spent a ton of time with channel marketing on how we could make the sales super obvious and easy. If you do that, you can move a huge amount of product, but if you don't think about the buyer properly and what they really care about, it doesn't matter how cool your product is. This is a theme that comes up a lot when I talk to other product leaders, which is, “I was really good at building widgets, but I didn't know how to sell them.” I would always tell people that sales is not a dirty word and every product manager should be figuring out how to go sell stuff.* **Greg:** Yeah, absolutely true. **Matthew:** *Maybe along those lines, if someone who is just starting their career comes to you and is like, “Hey, I want to get into product.” What kind of advice do you give them about how to get started on the path?* **Greg:** Normally, I first like to ask them about what it is that they're trying to achieve and what excites them about it. Because sometimes they'll say, it just seems like a cool role, and it's an exploratory question. And they'll want to ask me about what it's like to be a product manager or running a product team. I normally can tell what kind of advice they are looking for based on their why; no matter what, I'll hopefully give some helpful advice. If they are looking to break into product and let's say, for example, they want support from me. Where can I help? Well, I can help in my network. I can tell them, go talk to this person, and maybe they will have a role for you. But then I also tell them that the people they’ll be speaking to, their time is really valuable, right? In general, they're going to be nice because I wouldn't send someone their way if they weren't. But they're also going to be looking at how you can help them at the end of the day. They may not say it, but they're going to think of it like, I'm taking the time to speak with you; what's in it for me? Sometimes, people just want to pay it forward and help you out because they were once in your shoes. But other times, they are hoping to get something out of talking to you, and your job is to sell yourself or show them why they should be speaking to you. And ideally, you turn that into some type of engagement, like an interview or a job offer. So what I say is, go into those calls with ideas or suggestions; own the meeting. For example, if you want to go have an intro conversation with a Chief Product Officer at a specific company, don't just go in with basics like, “Tell me about your job, or tell me about the company, what are your pain points?” Those are helpful for context, but come in with a position that’s your own. You could say something like, “I was on your website; I signed up for your product as a consumer or as a business, and I just wanted to share my observations with you. I don't know a lot about your business, only what's publicly available, but this is what I think.” And give them your feedback. You're putting yourself out there, and doing this is exactly what product is; you don't have all the answers. A lot of it's opinion-based. Hopefully, you've got some data, but in the beginning, you don't. There are a lot of hypotheses, but part of product's job is to evangelize, convince, and influence. So, this is a great way of doing that at the most senior levels. When I used to interview more regularly and I would have a conversation with a recruiter, or even a CEO, I would have a deck. That deck would usually be a presentation of what I thought worked and didn’t work and observations that I came to based on my own research I did. That shows them how I think and how I influence my approach. So that’s what I tend to tell people if they are starting out their careers. And you’re not going to know everything. We’ve been around for a little bit, and we don’t know everything - we are still learning every day. But you're going to show you're earnest, you're curious, you're motivated. Some of your other traits might pop out. And if your goal is to get hired, and they don't hire you, stay in touch with them anyway. You can send them a deck later saying, “I was back on your website, and I thought this…” Use this as an opportunity to cultivate a relationship. Just remember to try and own a conversation because, at the end of the day, especially when we're talking over Zoom or Teams, people will get distracted really easily, so you need to keep them engaged. If you can build something, I went to PowerPoint immediately because that's sort of my go-to, but if you're technical and you can build something, even simple, you can show them and say, “I just built something because I had a couple of hours or a couple of days, and I just wanted to share with you” so they can see how you think and work. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:** *Since you're talking about hiring and you work at a hiring company, what is your favorite question (or set of questions) if any, that you like to use in interviews with PM's?* **Greg:** Let me answer this in two ways. The first way is regarding our business; we not only do assessments, but we also enable what we call structured interviews, which basically means that every candidate gets the same question. Ideally, those questions are aligned with the competencies for the role, and the people who are evaluating the candidates are all using the same rubric. The reason for doing this is that data has shown, over decades, that structured interviews are twice as predictive as unstructured interviews. An unstructured interview is usually the “Tell me about your experience.” and then they ask three random questions. In general, I like to ask specific questions, but it's not as important to me as everyone looking at the same rubric and all the candidates getting the same questions. So, for me, the questions I typically go to are: - Give me an example where you had to make a decision with imperfect information. What was that decision? What information did you have, and what was the outcome? - Give an example of a time when you didn't have enough resources to do something, and how did you accomplish it? *Because you hear people saying that they don’t have the resources every day.* - Give me an example where you had to influence someone who wasn't bought in initially on what you wanted to do. How did you influence them, and what was the outcome? *And give me specifics.* I'm really focused on specifics because I like to hear if they have numbers. Like, did they take this KPI from X to Y? Do they even have a KPI? How did they have that conversation? So those are the three or four of my questions. But what I really like them to do is I'll give them a homework assignment. And sometimes, it'll be very specific. Like, “Go through our signup flow and tell us how you would optimize it, or go to our website, just do your thing and come back.” And I'd like to hear how you would improve whatever you think needs improving. So part of the design of that is you give them a task that's very specific and you see how they do it. Sometimes it's vague because you want to see how they’ll work with a lot of imperfect information or no information and no guidance, which is sometimes, candidly, part of the job. You want to see how they think, how they get excited. Typically, I'll give them a week, or maybe less, to see how they manage under a little bit of time pressure. So think of it as a situational job test, and at a minimum, you get something out of it because, hopefully, they've got some good nuggets of ideas. Hopefully, at the maximum, you find someone who's just a great fit for your organization. **Matthew:** *It's super interesting, and we could probably spend much more time talking about hiring than we certainly can now, and obviously, it’s your business now. But, I've come away from all the hiring I'm doing, and, well, A: it's a crapshoot, and B: almost all of my instincts are incorrect, so they're totally unreliable.* *Like, when I go back, and I score myself on who I thought was going to be great or who I hired even though I was skeptical about them, I’ve almost always had it backward. Then I’ve thought about this idea of assessments a lot; how do you test? Especially because I think one of the challenges with product is it means a lot of different things in a lot of different organizations. And I've had experiences where I've hired someone who's had a senior PM title at a company, and they show up, and I'm like, you don't know how to do this job at all, what were you doing over there? You can’t just go on titles and experience, necessarily.* *So, how do you address some of those things, or what are some of your brief thoughts on it?* **Greg:** Not to get super deep into our product, but we can measure two things when candidates go through a hiring process. First, their cognitive ability; we can look at things like attention to detail and numerical reasoning, for example. I believe that, for certain kinds of roles in product, candidates should be pretty strong numerically, and you can test that really rigorously. Secondly, we can test from a personality perspective, and how suited a candidate is for a specific role like product management. We give guidance on a product manager role, for example, and their various traits, like, assertiveness, openness, competitiveness, or whatever it happens to be. You can decide in your organization what's important for you. You get a data-driven output, and you’ll see if the candidate has the cognitive ability and the right personality for the role. It gives you a numerical comfort, if you will. It's by no means foolproof; people can have the raw ability and the desire to do the role, but if they don't have the relevant experience, in some cases, it’s a disadvantage because you want them to have the relevant domain expertise. It's less important earlier in their career, though, when you want people who could just have the ability to do things. The way I test someone’s expertise is through that homework assignment and very specific questions. I seldom look at a resume; honestly, it's not a very good predictor. And there's going to be unconscious bias. I mean, there's data that shows over and over, if you see Google on a resume, you're going to automatically think a candidate is going to be great. But the reality is, who knows? I get very specific with my questions. So for example, I’ll ask, “Give me an example of a time when you had to create an initiative that didn't have any buy-in. What were the KPIs that you had? How did you move them?” If they aren't very crisp, or if they don't have the data or KPI on the tip of their tongue, they don't know about the metrics that they moved; you can tell pretty quickly if they may not be a great fit for the role. But again, hiring is hard; there are lots of different variables there. Humans are interesting people, and so, if I can do a plug for what we do, having a little bit of a more data driven approach to hiring can give you that edge. If I could say to someone, you can get a 25% edge in whatever you do, you would do it, right? And that's why I think I'm a big believer of assessments and structured interviewing. **Matthew:** *I should have hired you at my last company. Geez, I missed out. So far, I've exclusively hired people I already know, and that's been my trick at this company.* **Greg:** I love doing that because you know what you're getting. But generally, at some point, we have to hire junior people. And it's hard because I just don't have as much interaction with junior people outside of my organization or people who are starting their careers. And so that comes a lot harder. ***Matthew:*** *I agree.* **Greg:** This is not to answer any specific question, but the reason I love hiring junior people early in their career is that, in general, if you hire the right person who is open-minded and has a different way of thinking about things, I feel like I learn as much from them as, hopefully, they learn from me. One of my favorite meetings we have at the company is a flex topic meeting we have once a week where there is no agenda. We just come in and talk about things you've seen that you really like, products, technologies, whatever it happens to be. And it could be related to our business, but more often than not, it’s not, and it's just kind of general. The two things I love about this meeting are that, firstly, I just love listening and watching. I actually no longer attend the meetings, I just watch the recordings because I noticed that when I was there, the tone shifted a little bit, maybe because I was so engaged and started talking too much. But secondly, we use Figma to vote on topics and so it's like the wisdom of the crowds and people get to vote on what they want to talk about. I listen to the recordings, and I just love it because I learn so much about so many different disciplines that I wouldn't typically learn about. Even in my one-on-ones, like, for example, with our Head of UI/UX. She’ll show me all these different UI/UX patterns and how some work and some don't. She'll show me websites or I'll watch her go through websites and best practices, or how someone else has been using AI or a bunch of different large language models to do really amazing things. And I get excited about these meetings because I learn more in that 45 minutes watching than I probably would reading TechCrunch or the Wall Street Journal. ***Matthew:*** *That's awesome. Yeah, I completely agree with that point about large organizations, where just being in the room as an executive can really change things. And sometimes, you have to avoid meetings very purposefully so that they can be more productive.* **Greg:** Yeah. The downside of watching the recording is that I don't want to feel like Big Brother. **Matthew:** *Totally. I mean, it's really interesting with recording, I always joke that if you make it an expectation and it becomes background noise, then usually it's fine because they only get watched with good purpose, but it does make some people very unhappy, for sure, to have everything recorded.* **Greg:** I will say, going back to the AT&T experience of client calls, I’ve discovered Gong while at this job. Gong is really focused on go-to-market teams to help build and support better. I started playing around with it, and I realized that it’s gold for product discovery. So, fast forward four years, I get alerts every single day about keywords like, roadmap, feedback, friction. The AI is also good at summarizing and giving me nuggets, and then I also get to listen to the client. Sales and CS are hugely important for giving you feedback, but they can also have recency bias, meaning the last thing they hear can be the most important. Or, some will be very focused on (as they should be) figuring out how to best help a specific client because I can make money off of that client. Product people need to step back and be a little bit more realistic. Gong, for me, isn’t perfect because you are only getting your feedback in one way. But it helps with a better understanding of what the client is asking for. So, for example, a rep may tell me that a feature is super important to a client, but when I listen to the call, I can tell that that’s not what the client is saying at all. So when you talk to the client, subsequently, you have a really valuable conversation. I thought I would just mention that because I found it is a gold mine. ***Matthew:*** *I agree. We used a similar tool at my last company, Apto, called Wingman, which had the same basic premise. I owned both product and sales, which was an interesting position to be in. But it was interesting because we hired a lot of new people in product as we were building out the organization, and I needed them to learn a lot about our customers and our interactions. But it kind of got to the point where it became a drag on sales to have to invite all these product people to all of the calls. We had to explain to our customers why they were there, and they’d ask all of these questions, so it actually became amazing to just have the calls recorded. And we were all remote, so I could just give them a set of calls I wanted them to listen to. The instinct was great, to want to jump on calls and talk to customers, but there was actually an expense to the salesperson at a certain point.* **Greg:** That's right. ***Matthew:*** *To your point about AT&T, I remember I flew to Portland one time for two days and just drove around with the sales guys to get an understanding. And, I mean, that's a whole trip, you couldn't just do that every month, right? So it was very hard to keep up with what was going on in the market.* **Greg:** Yeah, great point. ***Matthew:*** *All right, well, I know we've gone for a while, so I just have two more questions for you. The first one I’ve been asking everyone is, how do you really build stuff day-to-day? What methodologies or tools do you use? Are you guys pure Agile, doing your own thing, or using Jira or something new and cool? I just think it’s interesting because I’m a tools nerd, so that’s why I ask.* **Greg:** It's a “depends” answer. Let me start from the beginning. We're a very transparent company in terms of ideas that come in and where those ideas stand, meaning will they become a feature, and what is the chance of them becoming a feature? We use Aha! to gather feedback, mainly from the go-to-market team, who will give us the Gong link, the revenue of the client, and the feature. So every day, I get an alert when the requests come in, and I’ll assign the request to a product manager. The goal for the product manager is to make a very quick decision about whether to consider building the feature or not. They can’t let it hang in purgatory; that's the worst. Our sales leader says it's like a maybe. And “maybe” is the worst in sales; you want to have a yes or a no. It’s very important for the go-to-market team to give the PM all of the background information because if that doesn’t happen, the product person isn’t going to listen to it. So we’ve been trying to train our go-to-market team to give us enough information we can act on. It’s only a one-minute process which helps us a ton. Once we have that, then the product person has to do the work to see if the request is something we’re going to focus on. Some of that is going to be their opinion, like, “I don’t think this is going to add a lot of value,” or maybe there won’t be a lot of revenue to it. This is where the go-to-market team has to make their case initially; why they think we should focus on it. But the product person needs to make some quick decisions on if it’s something they want to pursue. If they do, then they’ll probably do some discovery, meaning they’ll talk to some clients. My view is—and sometimes I think there’s some disagreement on this—is that I think you can talk to clients, and you need to ask the question, “Will you pay for this?” I don’t know if it’s a really great question, because sometimes clients will say yes, only because they don’t want to say no. But when the time comes for them to pay, they actually don’t. But what the product person is trying to figure out is if they believe that the feature would actually be something unique that we can sell. So, everything is in Aha!. Once they have conviction that it’s something we should build, we put a product value score on it. This is based on the revenue opportunity and the cost it would take us to build it. Then, every two weeks, we look at our roadmap and try to reprioritize things so we don’t do things that don’t meet a certain threshold, and the things that do meet a certain threshold, we do. And again, everything is in Aha! So it’s meant to be lightweight, but it gives us some idea of where we should be investing our energy. Now, I’d say for most of the product team, that’s the way it works. For newer initiatives, we’ve just gotten into a new business for us, which required a startup within a startup. So, we constructed a team of one product manager, one designer, and two engineers. The way they build is completely different. Basically, they’re just talking to customers, talking internally, then deciding if they want to build something. There are requirements, and there’s design, but there’s no prioritization process because the team is talking all the time and they’ve decided to make it truer to Agile. So, to answer your question a little more directly, we’re not quite waterfall at all. We release pretty regularly, and we try to make it as nimble as possible, but we’re not quite Agile if that makes sense. So we try and find a happy medium for most of our business. But, for the other part of our business, we’ve been quite agile and I’ve been ecstatic by the results of that team in terms of them delivering product. And then from a tooling perspective, it's really Aha! And Jira. Our design team uses Figma quite a bit. There are some other edgy tools that we use, but there's nothing, there's no tool that I think you haven't heard of before. ***Matthew:*** *Yeah, well, it is interesting to hear what people are using because it does vary. There are so many out there. I've heard some interesting ones so far.* **Greg:** I know our design team loves Figma, and it has great plugins for developers too, so they're using it as well. ***Matthew:*** *Figma is everywhere, they totally took over. It's really, really amazing.* *So my last question may be the AI question that we talked about earlier, but how has product changed over your career, and where do you think it's going?* **Greg:** I can talk about how we use AI. Personally, I love using it, and there are two main ways that we’ve used it; one internally, and one in our product suite. Internally, I would say about 20% of my team’s time is focused on inbound questions from the go-to-market team, which are usually from them getting inbounds from clients or prospects about feature functionality and capabilities like, “Can you do this?” I would say that many of them are repetitive, meaning that we’ve had those questions before, whether that be six months ago or a year ago. What happens is, that a go-to-market team member will post it and tag the PM who is in charge of that request. What we’ve done, is we’ve leveraged one of the large language models to build our own instance to support the go-to-market team; we call it Criteria Chat. We publish our roadmap internally to the go-to-market team on a quarterly basis about a year out so they know what's going to be coming, they can speak to it, and they're knowledgeable on our roadmap. You can ask Criteria chat questions like, “When is this feature going to be available”, but it can actually help you. You can prompt it to say “I have a customer or prospect who objected to this. How would you answer this, or how would you respond?” And now you start getting really good responses, either on the fly or in email, that are tailored to our company’s delivery and what we do. And it’s specific because we’ve trained, or fed, our large language model with a lot of our internal data. So that’s one way we’ve been using it that has been really helpful for us, and it’s just going to get better. The other way we use it is from a product perspective. We’re in a fairly regulated industry with hiring rules and regulations, and with AI in particular, and there are a lot of laws in existence, especially coming up in New York City in particular. So the way we’ve used AI is, it has to actually solve a business problem; we’re not just going to use AI just to say we do AI, it has to allow us to do something better. With that mindset, we are able to build products that we simply couldn’t have done without using AI. For example, we recently launched an English Language proficiency assessment, which looks at how well someone can speak, write, read, and understand English. Some of those things, like reading, are easy to do; you can do multiple-choice, for example. For listening, you can have them listen to an audio and then give them multiple choices. But writing has been really hard because historically, you would have to outsource those writing components to a third party that would look at the writing samples. It would take 24 to 48 hours if you were lucky, and it was really expensive. We were able to build something using our organizational psychology expertise, and it took a long time. But what we can do with our model, is that it not only looks at what an individual wrote grammatically, sentence structure, use of words, et cetera. But it actually has the context and is context-aware. So they see a picture, and they have to write about it. So, if I wrote a perfect paragraph or a couple paragraphs, but had nothing to do with the image, the system would score it poorly. And so we've had to train this model, and the clients get an instantaneous result. So we've been able to do something that is much faster, and much cheaper that we wouldn't have been able to do without leveraging AI. ***Matthew:*** *Does that picture, in part, help you avoid the cheating problem? This was just in the journal the other day, about AI buffed-up resumes, right?* **Greg:** I read that article as well, and it was interesting because I think that a resume has some value, but it’s not great for hiring. The data has shown, I mean it was bad before, but now it’s even worse because you can use ChatGPT or whatever model to say, “I’m applying for this job, give me the perfect resume.” But the reality is, is that the resume is probably inaccurate or at least embellished. It doesn’t tell you, “Matthew is a great fit personality-wise and cognitively.” So the reason we show the image is for exactly that reason. We don’t want someone to just copy and paste. We have measures that don’t allow them to do that anyway, but we don’t want someone to just write some random stuff. So the idea of the picture is to make sure they understand what they’re seeing and can write about it in a way that is contextually relevant. We can talk about AI and cheating another time, though. It’s a bit of a hot topic at the moment. ***Matthew:*** *Yeah, one of my old interns from way back when I did Wallaby started an AI cheating detection company actually. But it is funny, we use a bunch of it internally. We use ChatGPT to help with stuff, I think we use it very in the assistive model. We have this whole funny thing where we're very honest with each other, because it's not that anyone's cheating by using it. But we’ll be like, was this ChatGPT? And sometimes you're like, yeah, absolutely. And it loves certain words, so sometimes you can kind of tell. The other day someone said to me, “This sounds like ChatGPT” I was like, “Hey that’s offensive.” And they said, “Well, you used the word delve.” And I said, “You're right, it does love that word. But so do I!”* **Greg:** Was it ChatGPT? ***Matthew:*** *No, it wasn't. I had actually written it. That's why I was offended because I would totally own up to it. But I did actually write this. It was very funny. But all those tools like Grammarly, which I’ve been a user for years, but I’ll use it to do my own first pass for editing because it will see stuff you missed or you can apply style guide rules, and I think all of that stuff is super helpful.* **Greg:** Yeah, I find if you can find a good tool, continue to use it. I’m in this networking group, and we go over tools we use all the time. There’s this one woman who spends like $600 a year on all these random tools, and I just think, I would rather just wait for Microsoft to come out with AI, because those are three tools I know they should be doing, and I would, candidly, rather just wait a year for it to come out rather than switching tools all the time. Which I know is odd for me to say, because I figure that as a product person, we should be an early adopter of those things. But if you go back to Jeffrey Moore crossing the chasm, most people are not early adopters, they’re kind of in the late adopting stage. ***Matthew:*** *Yeah, and our industry is so tool-driven. It’s interesting because, I still do a little bit of writing random codes, like little scripts to do things, and I’m a terrible engineer which is why I’m not an engineer. But it’s super great for debugging. I can give it something and say “Hey, this doesn’t work” and it will tell me that I was missing a semicolon. Or, rather than spending an hour searching Stack Overflow, it can do that for me.* *It’s funny because there’s really a trade-off, right? Especially in our industry, where we’re relatively highly paid people. If your average salary is $180,000 a year as a product manager, and you have the option to spend $200 on a tool that will make you way more productive, it’s easy to think, “Why the hell not?” But next thing you know, your tools budget is enormous. It’s a challenge, but individually, it feels like a really smart move. Like, if I can save them 2 hours a week for $200, what a deal.* *Thank you so much for your time today, Greg, it’s been great chatting with you.* **Greg:** Thank you for the opportunity! Hopefully, it wasn't too meandering. ***Matthew:*** *No, I loved it. It was super interesting. And it's fun to talk to people and ask them questions that you don't normally ask people because you already know each other. I’m having a blast doing this, so thank you!* ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Product Talks with Meredith - ProductFTW #34 URL: https://www.productftw.com/product-talks-with-meredith/ Last updated: 2026-05-22T01:57:20.000Z For our third post in the [Product Talks](https://www.productftw.com/product-talks/) series, we chatted with Meredith Brown. She is another former AT&T Interactive colleague of mine (are you sensing a trend)? Meredith stood out to me immediately as a super-sharp product leader and moved from AT&T to Salesforce and ultimately to Pantheon as CPO. We spoke just before Meredith started in her new role at Smartsheet. ![Promotional graphic for Product/FTW’s 'Product Talks' featuring photos of Matthew Goldman and Meredith Brown against a gradient background. The tagline reads, 'It’s like a podcast, but you have to read it.'](https://www.productftw.com/content/images/2024/11/Meredith-Brown-1.png) **Matthew:* Hey, Meredith. Let’s start with you telling me a little bit about yourself. I know you're about to start a new role, so you can tell me either where you work or where you have worked.* **Meredith:** Hi, I’m Meredith. I'm starting a new job at Smartsheet next week, where I'll be leading the enterprise and ecosystem product areas. I am coming out of a role as the chief product officer for a company called Pantheon. Pantheon is a web ops platform for front-end developers, mostly for developers who are building their websites on Drupal, WordPress, or other sources of open-source technology. It's a platform that allows them to manage all of the different processes around getting a website to development and onto production. Pantheon does that with a good degree of quality, scale, and performance. I ran the Product and Design teams there for about 18 months, and that was a very different experience than some of the other roles I've had. It’s a small company and it's privately owned. When I started, there were about 500 employees, and when I left, there were about 350\. So, it went through a lot of organizational changes while I was there; I was running product and design, and then for a period of time, I was running engineering as well. So I definitely got a broad perspective in terms of not only how product works and how to lead product, but how design works alongside product. I also got perspective on some of the challenges that come with working alongside engineering and having responsibility for that function for a bit of time. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:* I want to discuss that further, but I have some further intro questions I want to make sure I don't miss.* **Meredith:** Absolutely. Before I was at Pantheon, I was at Salesforce for almost nine years. So, I saw lots of different parts of the Salesforce ecosystem and then had the opportunity to be Head of Product and General Manager for the Pardot business, which is a B2B marketing automation platform. **Matthew:* So, when you were growing up or going to university, what did you study, and what did you think you were going to do?* **Meredith:** This is such a good question because I'm thinking about that for my own kids, who are starting to think about college and my experience versus their experience. When I went to university, I studied Communications & English, and I had a minor in Spanish. So, I obviously did not have a Computer Science background. I was very much focused on the humanities*So, what do you think about the role of a chief product officer versus the role of a product manager at various levels?*. When I came out of school, I still didn't know what I wanted to do. So then I went, and I got a Master's in Health Communication, and I thought that I was going to work in public health and do these big public health campaigns to try and convince people to change their behavior. But I quickly realized that that's a really hard career to go into when you have a lot of student loans. So I went into consulting, and I started working with different companies that had different business challenges and were using technology to solve them. I realized that I really liked that creative process of figuring out what the problem is, how we can solve it, and also how we can work as a team. I was an athlete growing up; I played a lot of soccer and lacrosse, and I loved the team environment. I realized I would really enjoy it if I could marry what it is to work in a team environment and have really good communication, that's what led me more to product management. It was a pretty different way to get into it compared to the other path that many product leaders go through, which is coming from a computer science or engineering background. I came at it from more of the business and user end of the spectrum. **Matthew:* What was your first product manager job?* **Meredith:** Well, I left consulting, and I went to Blue Shield of California and took on an internal role. What Blue Shield was doing at the time was trying to figure out how to take all of their manual, paper-based processes and digitize them. I was thinking about functionalities like member self-service, the providers submitting claims, how agents and brokers work in the ecosystem, and how employers go and buy health insurance and then onboard all of their employees. All of that work needed to completely change and transform. I don't even know if we called it a product manager at the time, but I was the liaison between the e-business group and end users, and I had to figure out how to balance what we wanted to do as a company versus what it would look like for the end users. I quickly realized that to be a true product manager, I needed to build products that you price, package, and bring to market. At this point, I transitioned to AT&T Interactive, where you and I met. That was my first switch from an internally facing role as a product manager to an externally facing role, which eventually led me to Salesforce. **Matthew:* So, if someone asks you what product management is or what you do as a product manager, how do you answer?* **Meredith:** I always say I'm the person who tries to figure out the value that we can deliver to our end users. I've always worked in a B2B context, so in that case, not only for our users but also for the business. So, how we think about products and thinking about things like, how do we develop them? How do we launch them in a way that gives value to an end user and also allows us to reach our business outcomes? **Matthew:* One thing you touched on was in your role at Pantheon where you were leading other functions like design, which I think is very common for product leaders to manage, but also engineering. I'm personally seeing a lot more CPTO-type title roles. So, what do you think about the role of a chief product officer versus the role of a product manager at various levels? In your ideal world, what things are you responsible for? What structure would you prefer to work in if you were drawing the boxes?* **Meredith:** I think the biggest thing that I learned stepping into the CPO role is that your first team (in terms of who you’re working with) changes so much. If you're a product leader, your first team is your product peers, and maybe design and engineering. When you're stepping into a CPO role, you really have to think about the outcomes for the entire business. So you have to have a perspective not only on what's going on in product, design, and engineering, but you have to have a lot of empathy for sales, marketing, customer success, and all of these other functions because you're really an officer of the company. You have to think much more strategically than just your product. I think that's probably the biggest difference between being a product leader and a CPO. It also means you might step into something like, “Hey, run engineering for four months.” You have to have that general leadership ability to be able to go in and understand what's going on in the ecosystem and understand how all the pieces fit together. It’s different from being a product leader, where the focus is on getting the product to market, making sure people are adopting it, and making sure we're hitting our revenue targets. You still do all of that as a CPO, but you also have all of these other things to think about from the perspective of what's happening across the company. **Matthew:* I think your background is really interesting in terms of comparing the CPO role in a 300-500-person company versus the CPO and GM role you had inside Salesforce. What are some of the key differences in terms of how you approach part of being a "division," or, I don't know what term Salesforce uses, but an important leader, but in a bigger context? Like at AT&T, we had a CPO of AT&T Interactive, and then obviously with a much bigger company overall.* **Meredith:** I think the biggest difference was that at Salesforce, there was always another layer of escalation. If something was going on, you had an entire research team, legal team, and communications team; there was always another function that could own an escalation or a challenge—if there was something going on, there was always someone you could partner with. When you work in a small company like Pantheon, where there are only 350 people, and you are the chief product officer, you're the person solving all those problems. It's a very different type of role where you roll up your sleeves, understand what the issue is, and move people through it. When I was at Salesforce, I felt like there were always mini-teams behind anything that we were working through. **Matthew:* That's super interesting. Both of those platforms obviously have customers who want access to them all the time, so I’m curious about how you handle a situation where systems go down, or there’s some kind of security crisis or something like that. How close to the metal are you getting? Are you on incident calls, or are you asking your engineering leads to manage it? How do you deal with some of those challenges?* **Meredith:** Since I was a GM of the business at Salesforce, if there was a big issue, I was on many of those escalation/incident calls working with customers. So, being in a larger company doesn't get you away from that part of it. But at Salesforce, there was a whole ecosystem around how that would work, a whole team that would own all of the operations. There was a whole implementation of pager duty. And it was a pretty well-oiled machine in terms of what happened when an incident happened; you got on Slack, and all of the communication was very streamlined. When you compare that to a smaller company like Pantheon, all those things are in place, but maybe the processes aren't as mature. So you're kind of working through a lot of the playbooks and refining them as you go. I felt like the Salesforce playbook was pretty tight because it was such a big organization, and there were so many different pieces of the puzzle that had gone through incident management. At Pantheon, I was also writing a lot of the comms myself, whereas at Salesforce, there are more templates and more playbooks to lean into. **Matthew:* That makes me think of when we had an incident once at Bankrate. It was a vendor mistake, but it caused inquiries to show up on people's credit reports that weren't supposed to. I went on Reddit to be like, “I'm the Head of Product at this company, and we're really sorry.” That was our comm strategy. Because it was blowing up in some subreddit about credit cards. It was a very, like you said, roll up your sleeves type of thing.* **Meredith:** Absolutely. **Matthew:* So, shifting gears a little. If someone comes to you, and they’re in college or recently out of college, and says they want to be a product manager, what do you tell them about general advice, how to get into the role, or how they should think about it?* **Meredith:** I think, first of all, it depends on what kind of product you want to get into. Like, are you going to go into a consumer-facing product or a B2B product? Do you want to go into something like a platform and very technical, or something that has a lot of experiences and interactions? And so the advice that I'm going to give is going to vary based on how they think about the types of products that they're curious about and they're interested in because there's a spectrum. So if someone's very technical, they're coming out of engineering, and they want to work on platforms, well, then I'm going to give them a set of advice around the types of companies that they should be looking at, the mentors that they should have. There's going to be a lot more of those product managers that maybe came up through the engineering ranks. If they want to go on the other side and do something that's really creative, I might say, how are your design skills? So it really does depend on the type of Product that you want to go into. And then once you have a sense of what kind of Product you want to be doing, gear your experiences towards being surrounded by people you're going to learn a ton from. **Matthew:* Are there books, newsletters, tools, or experiences that you recommend to aspiring product managers?* **Meredith:** Absolutely. There are so many good resources out there that you and I didn’t have access to when we were younger product managers. I think [Lenny's Podcast](https://www.lennysnewsletter.com/podcast?ref=productftw.com) is great because he does a lot for leaders and individual contributors. There are lots of different meetups out there where you can really build your network. For example, I'm going to this product leader summit next Thursday. Maybe you're not going to a product leader summit, but maybe you could go to some other sort of product management summit. The other thing that this cohort of new product managers has that we didn't have is all of these amazing AI tools where they can have conversations about things that they're curious about. I personally like [Perplexity](https://www.perplexity.ai/?ref=productftw.com) because it gives me sources. I like to have a conversation with it, like, “Hey, I'm really curious about this framework,” and then you can ask it more questions and go in and get the resources. So, if you're an aspiring product manager and you're not taking advantage of all of these amazing new tools, I think that’s a big miss. **Matthew:* For sure. I normally ask in the context of your current job, but since you’re about to start a new job, you can pick any experience you want for this next question.* *What do you use in terms of methodologies and tools? How do you actually build the software? What are some of the methodologies you use - are you strictly Agile? Is your preference something slightly different, like gung-ho Jira or hate Atlassian? What are you actually using on a day-to-day basis when you're building stuff?* **Meredith:** I came from an environment where we were using Jira, which was fine. I think that because I was a chief product officer and I had directors and VPs who reported to me, I expected them to be more involved in how we used the tooling. For me, coming into a new role, it's probably more important to understand if we have a compelling vision that everyone is on board with and understands. Do we have a set of priorities, and do people know what they are? Tooling doesn't really matter to me as a leader as much as having that compelling vision alignment across the team around what we're working on and why. You have to move people together toward that vision and those outcomes. I spent a lot of time refining that vision and making sure that we were listening to our customers, understanding what was happening with our competitors, and listening to our internal stakeholders, too. I also ensure that the broader team, including engineering, really understands the why behind what we're building. That's for my role, personally. I know there are other people who spend a lot of time on the tooling, but I put a lot of my energy into constantly communicating with the teams about what we're doing and why, making sure that they understand why we've put things in the priority order we have, and what we expect those outcomes to be. **Matthew:* So, how do you ensure that alignment? It might not be a software tool; maybe it’s a method or process. Is it presentations? Is it OKRs? What do you like to do to bring folks together?* **Meredith:** I think it can be OKRs or whatever the company is using. What I do is start by examining the company's goals, and a lot of that starts at a fiscal year. Once I understand where the company's going and what we need to do, I then look at how I can translate that into a set of pillars, or whatever you want to call them. Pillars, strategic priorities—every company calls them something different. I then create a list of things that we're going to work on within a certain period of time that is contextual to where the business is going. Typically, we have no more than ten. We then go through them as a team, and we make sure that there's time for feedback and then we figure out what the measures are around those ten things. We look at things like if there are any obstacles that might get in our way as we go through the goals. And then we run that through a quarterly business review and cycle. I like to come back to it halfway through the fiscal year and then refresh it with what new information we have at that point. Has our competitor done something? Has something in our business changed? Have we completed one of the things that we said we were going to do? So we kind of refresh it and that's where we maybe become more Agile. It's not set in stone that we're going to do those ten things forever. We have to be agile and react to what's happening around us, but we do it within the context of a framework so that people have the right cadence in terms of how they work together and that predictability around understanding how we work together. **Matthew:* How do you approach the cross-functional component of things? How do you communicate to your product or product design team? And also, as you mentioned, not just engineering but also sales or support or any of those other functions. What do you think is the best way as the Head of Product to use your influence to create that alignment around what you think are the right product priorities?* **Meredith:** I think it's a two-way street. We, as product leaders, have to listen to what's happening in sales and customer success. And hopefully they're collecting lots of data for us to help us understand what's happening. Like, are they losing deals because of something that's happening in the product? Are they winning because we're doing something really well? Do we have a lot of red accounts because of certain product issues? So, we hopefully have some good communication and feedback loops going through to help us really understand what's happening in the go-to-market teams. I'm using that information to influence what's going to be important for the product team, so they can see their voice in some of the priorities. I also like to use monthly or quarterly business reviews to reinforce what we're working on and why. And if those other teams have new information that they want to bring to the table, they have a forum where they know that their voice will be heard. We're not always going to work on everything that they want, but they at least can understand how we're evaluating it and how we're making those decisions. **Matthew:* Awesome. So, after all of that, what's the most rewarding part of product for you? Amongst some of these challenges and some of these good parts, what do you love about it?* **Meredith:** I think it kind of goes back to why I got into it. I love being in a team environment, having grown up playing team sports. I love the element of the Product launch being kind of like a game. We win sometimes, or maybe we'll lose, and we learn from it. I love that part of it. I love the people, the connection, the relationships, and getting people to work together through some sort of outcome. The other part that's super rewarding for me is building something for a company in a B2B context, which is where I've mostly worked, and it helps them do something great within their company. Like if I change somebody's career trajectory because we made their life so much easier. If they come to you and say something like, “Every day I had to run this report, and it would take me months to do it, and now I can do it in two weeks.” Those types of things I always find super rewarding—when you're materially changing somebody's work life or the way that their business is run. **Matthew:* You keep using this sports team analogy, which I love. What role do you think the PM is playing? Are they a player? Are they a coach, are they a General Manager, or are they something else? Like in the world of sports. And what player is the chief product officer playing when you think about that same analogy?* **Meredith:** I think the chief product officer is definitely like the coach, right? You have all these players on the field, and in my mind, I’m thinking about a basketball team where you're passing the ball around. So I think the chief product officer needs to understand that your different players have different skills. And that includes your engineers, your product managers, and your design team; everyone is on the court. You have to kind of understand how all of those pieces fit together. So, I think the CPO needs to be the coach of that. One of the things that I always coach the product managers on my team on is that you don't have to do everything by yourself. You might be on a team with ten engineers, a really kick-ass designer, and a researcher; you can leverage them. They have so much knowledge as well. So, you should be looking at how you can bring out the best in your own team to get the best result for what you’re building. I think sometimes product managers come into their career early stage, and they think that they have to do everything. And I'm like, you have so many smart people on your team - why would you do that? You should be looking at how you can get the best out of everyone. And then they're excited because maybe they're being stretched in a different way, or you're giving them an opportunity like getting on a customer call with you. So I think they should have that growth mindset and think beyond just being a product manager. You can actually be kind of like a coach for your smaller team as well, and help your engineers and your designers and your researchers and other folks grow their careers as well. **Matthew:* I think it's really interesting. In fact, just the other day, I was having this discussion with a former CTO/friend of mine about the analogy that PMs are the CEO of the product. And the way that you're putting it, as a coach, is really interesting. It's a different role because, as a PM, you're on the team, but you're not necessarily the same as your teammates. Usually, not everyone directly reports to you in a management structure, but you're still a leader.* *So, maybe this is a controversial one: Is the product manager the CEO? Also, what's the difference between you, in this case, as the chief product officer/coach and the product manager as the player/coach? How do you think about different approaches or tools that people need to leverage to play that role?* **Meredith:** The one thing that I don't like people thinking about the PM being the CEO is that you don't have control over how all of the company’s resources are allocated. And so I think that you could set yourself up for a lot of frustration. Like, if we tell our product manager that they’re the CEO of a part of the business, there could be some frustration if they don’t have enough resources, like engineers or designers. Like, I'm not the CEO. I have no agency here, so that's why I don't like that. **Matthew:* That's fine. I've always hated that saying. I didn't want to lead the witness, but I've always hated that analogy. Having been both a CEO and a product manager, I think they're not the same job at all.* **Meredith:** Yeah. Because the ask of a product manager versus the ask of a CEO is very different. For a PM, we ask them to work with the resources they have, with what they know, and with what they're being asked to do. And the outcomes you're trying to drive are more around finding the best solution that you can. Which is a very different ask than being the CEO of your business. Because we're asking PMs to make trade-offs. We're asking them to sequence things, to make the hard calls, to think creatively. I would much rather them show up with that curiosity and that creativity and being able to collaborate with people; that's a very different expectation, I think, than saying, “Be the CEO of your product area.” Because what is the behavior that you ultimately want from your teams? You want them to be outcome-driven. You want them to be curious. You want them to be collaborative. **Matthew:* How do you help PMs on your team learn to coach or influence the other folks they have to work with but who are not their direct management employees?* **Meredith:** Some people naturally have that skill set. I don't know if it's personality or what it is, but sometimes you're going to get lucky, and they're already super collaborative. Maybe it’s the way they're educating people coming out of school; they're familiar with project-based collaboration, and they know how to do it. Occasionally, you do find the person who has the mentality of “No, I’m the product manager, so what I say goes.” If you have that mentality, it's not going to really work well for you. So I try to find opportunities where I can say to them, “Look, you have all these things on your plate. What if you gave this task to the Lead Engineer or this particular person and let them run with it for a little bit.” Get them to let go for a bit and encourage them to practice and to learn to trust their team and see what sort of results they can get. **Matthew:* All right, so last question: How has product changed over your career, and what do you think the future of it looks like?* **Meredith:** I think that technology is always evolving; that's constant. And so knowing that technology will always change is something that I think we as product managers have to always lean into. There's so much that's happened in the last couple of years with AI and generative AI. I don't expect product managers to be the experts in every technology because it will change, but I do expect them to be able to adapt to change and know that change is coming. So, thinking about things like how you will adapt to it and what kind of frameworks you can always lean into. Because that change will come. The one thing that won't change is that you have to understand what your customers are asking for in terms of the problems they want you to solve. How do you constantly remain curious to understand those problems, and how do you not give them exactly what they asked for but think creatively about how to solve their problems? It really comes down to problem-solving. I think that's the thing that will never change with product management; you will always be a problem solver. **Matthew:* I agree. Awesome. Thanks for chatting with me today, Meredith!* ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Product Talks with Corey - ProductFTW #33 URL: https://www.productftw.com/productftw-33-product-talks-with-corey/ Last updated: 2026-05-22T01:57:21.000Z *For our second post in the* [*Product Talks*](https://www.productftw.com/product-talks/) *series, we’re talking to Corey McMahon, Chief Product & Technology Officer of HopSkipDrive, a late-stage startup that provides on-demand and scheduled 1:1 transportation for youth. I met Corey when he joined AT&T Interactive through a rotation development program. While we were on different product teams, we sat in the same pod of desks and we had a number of opportunities to collaborate.* ![](https://www.productftw.com/content/images/2024/10/Corey-McMahon.png) **Matthew:* Thank you for doing this, Corey. Let’s start at the beginning - what’s your name, where are you at in your career, and where are you working right now?* **Corey:** I’m Corey McMahon, I’m the Chief Product and Technology Officer at HopSkipDrive. That means I’m responsible for our Product, Design, Engineering, Data Science, Analytics, and Information Security teams. **Matthew:* What did you study in college, and what did you think you were going to do when you grew up?* **Corey:** Great question. I grew up sitting around the table with my dad and uncle, who were both small business owners and ‘CEOs’ if you will, although I’m not sure they actually held those titles. I saw that they often talked about both the people side of what they do, like managing people and customers, and then kind of business strategy, like “This new thing happened, what are we going to do?” Those two things always interested me, so I went to UCLA and studied communication studies—specifically, interpersonal communication—and eventually followed that up with an MBA. Early on, I had no clue exactly what I wanted to do, but I thought maybe management consulting was a path. I did some management consulting internships, primarily supporting the public sector. In Business school, I actually had the entrepreneurship bug, and I wanted to start a video scouting platform for college sports teams and eventually pro sports teams. I had connections from being a manager for UCLA’s basketball team, so I had a bit of an ‘in’ in that industry, so I thought I might follow my dad’s footsteps in starting my own business, but I didn’t pursue that path. **Matthew:* How did you go from that to becoming a PM? What was your first PM experience, and how did you end up getting that job?* **Corey:** Everybody comes into product management differently. I came in sideways, I would say. I came out of Business school looking to do corporate strategy without the travel of a management consultant. So I went to AT&T, and they had a leadership development program where you could rotate around a bunch of different business units within AT&T, with the intent of giving you a view of all things AT&T while giving significant leadership training, so you could make a bigger impact with higher leverage. My thought was that I would end up in a corporate strategy role there, at AT&T, but after going through that process, I was looking for something faster-paced and something a little more tech-oriented. Eventually, I landed at a subsidiary of theirs called AT&T Interactive which was my first real taste of a tech company. I joined in more of a Business Management role rather than Product Management. I was managing the publisher network, and as part of that, I became the owner of our strategy of “Where are we going next with this?” So it started from business strategy, and from there, we started to ask, “What are we going to need from a technology perspective?” We saw we’d need some ad-serving technology, and we’d need certain things from a user experience. I then started partnering with Product Managers and Engineers as the business owner for a portion of the platform. Over time, that role became more and more technical. If you're going to have a viewpoint of where we ought to go strategically, and you're going to prioritize what we do, that starts to look a little bit like Product. If you're going to understand the unique value proposition or the sequencing or relative impact of things, it begins to look like Product, too. And so I actually managed Product Managers before I was a Product Manager and grew up in the Product Leadership track. Eventually I founded a startup and had to be very hands-on as I was the Product Lead. And so I essentially had these simultaneous paths, where I was learning how to be a Product Leader while then simultaneously learning how to be the actual PM on a product. **Matthew:* And so, to finish that all off, how did you end up at HopSkipDrive?* **Corey:** So that company, AT&T Interactive, eventually spun out from AT&T as a standalone business, and I took on larger and larger and more and more technical roles there. I helped re-platform that business and rethink the product portfolio. The business was in the Yellow Pages industry, which was declining, and eventually, we ended up being acquired by our largest competitor. Soon it was time for me to find the right next opportunity, and my first boss at AT&T Interactive was Joanna McFarland, who founded HopSkipDrive and is our CEO. She was looking for someone to help lead things internally as she was focused externally. So I came in and took on Product and Operations, in a COO type of role, when we were fairly early stage (we had just closed our Series A), and the rest, I guess, is history. **Matthew:* So AT&T, I thought was interesting in that you, at least once you came out of the leadership program, reported to Joanna. Joanna and I were peers, and we reported to the Chief Product Officer. It was the Product Management team, but we had this delineation between what we called Business Managers and Product Managers, which I actually think that they're the same thing. And there were a lot of folks who were very adamant about what they perceived to be less technical Product Managers, which, not to get into my story but used to frustrate me because I actually am quite technical and have written a bunch of software. And they perceived that because I had this title, I was not technical.* *So, how do you think about what Product Management means to you, both from that experience and now? And taking a step further, is it a technical role that requires you to be an Engineer (which you’re not), or is it broader?* **Corey:** I love thinking about this and honestly grapple with the answer to this day, partly because I think the discipline of Product Management is so wide. The responsibilities could involve anything from market analysis and user feedback all the way through to QAing the feature before it goes live or go-to-market and communications. Not to mention, the demands of the job are materially different as you scale. So, depending on your industry, scale, and the type of products you make, it can vary widely. You could have a product manager at a CPG company versus a hardware company. The role and responsibilities are just so broad. And so, while I share some of your sentiments, there's certainly that stereotypical answer that “it depends.” So to me, I will say that Product Managers absolutely have to understand the way a system is architected at its fundamental level, have to understand how data flows back and forth, and have to be able to communicate clearly with Engineers. You also have to develop a really strong sense of what's technically feasible and how long something should or shouldn't take. Those things require a certain level of technical understanding, and you can't be an effective Product Manager, even if the role is defined as fairly business-oriented, unless you're able to do that. And so oftentimes, those skills come from having lived it and having been an Engineer, but that doesn't mean you have to have been an Engineer to be successful. We grapple with this question a bit even today at HopSkipDrive, because we have both an online and offline component of what we do. We’re a digital platform, but the experience happens in real life, and so there's a very operational component of what we do. Some of the things that we would do to improve the Product experience could be something like rolling out billboards on the campuses of our school partners that say, “This is the HopSkipDrive pickup line.” Is it best suited for a Product Manager working with Engineers to “project manage” that rollout? Or is that responsibility better suited for somebody else? Is that an Operational role? Or even the strategy of deciding what the Operations team wants to do or want to look like; where should that ownership and accountability be? So in many cases, where we have a core product, with product-market fit that we're trying to grow and push, we try to put Business or Functional Owners, Product Managers, Designers, and Engineering leads together in sort of a ‘four in the box’ type of model where they share accountability. The Business Owner owns business metrics, and the Product Manager shares those business metrics, as well as some product metrics they're accountable for that may move faster and are more directly tied to them. Whereas when something is a little earlier stage, Product's taking the lead and needs to partner with a technical counterpart, and probably should have the business strategy and be driving that themselves. **Matthew:* I want to dig in on that structure, but I want to come back to what you said about the physical world. That really resonates with me because I used to work at Green Dot. Green Dot is a technology payments platform that sells its product at retail, or used to (it sells it online now), and one of the reasons I went to AT&T was because I wanted to work on the Internet.* *I actually spent 90% of my time talking to retailers about pieces of cardboard in their stores because our acquisition channel was entirely physical. I spent an insane amount of time on what the package looked like, what it said on it, how it was constructed, how it was printed, what color it was, and it was just like traditional CPG Product Management. Although I also did API connections to the retailer's point of sale, and it was very slow-moving because it was retail.* *So I think it's a really interesting point that a lot of people think about Product as Software Product Management, and that's obviously a large part of what we have both done. But there's so much more - many products have hardware, with operational needs. And I think you're right, that Product Managers have to own a lot of that.* **Corey:** I think that's right. And to me, the purest image of what people think of as a Product role is if you have an entirely digital platform, you’re a B2B SaaS player with Product led growth motion, and that's where the easiest answer is. Things just get more complicated the more real-world components you layer in there. **Matthew:* Let's return to how you're structured at HopSkipDrive. Correct me if I’m wrong, but my impression is that you've been there long enough and early enough that the Product Org probably looks like you want it to. And so, what are some of the tools or systems you guys use? Are you guys agile? Do you use Jira? Are you none of these things? What's the methodology for how you actually build products, and what do you expect your PMs to be doing?* **Corey:** The first thing I have to comment on is the fact that the Product Org and the Product processes today reflect what we need at the moment with an eye toward what we will need in the future. We haven't gone more than six months before something material has changed about how we're organizing ourselves, how we're structuring the work, and how the product processes have gone. Which is the story of a startup turned scale up. And so even to this day, much of my job is actively changing our software development lifecycle or who's in what seats on the bus or how the processes work. And so there are things that we do today that aren't exactly how I think they need to be six months from now. Digging into this a bit, our Product Managers are primarily focused on particular portions of the business problem that ladder up to key business KPIs, typically have clear business partners, focus on a particular end user, and where we can define clear product goals and KPIs. It doesn't always work out that way, but that’s the primary model. For example, school districts are one of our key users in the platform, with a primary web app that they use. We have a PM who's responsible for the client experience and everything associated with our clients. His ultimate business outcome might be net revenue retention, which he shares with our VP of Client Experience. However, he also has more product-oriented key results, like active users per account or time spent per ride booked. We pair him with a Designer and an Engineering pod led by an Engineering Manager, and they work hand in hand on the roadmap. So, using that one PM as an example, he works directly with sales, support, and clients to solicit feedback and is prioritizing a roadmap based on impact to the ultimate goal. From a tools perspective, we currently use ClickUp, which is more of an Asana or Trello. It's a fascinating tool because it tries to be everything for everyone - for better or worse. So it is currently our company Wiki; it's our product roadmap, and it's all sorts of other things. That's where we collect the ideas, prioritize them, and size them. We write what would be essentially a PRD in other places, although it isn't defined that way; it's just in the description of the epic within that. That's where we do our prioritization, and as things go through scoping and design and then once they're tech planned with the engineering lead, we actually then turn over and create specific engineering tickets in GitHub. GitHub is where our engineers are working for both tickets and pull requests. So a typical epic might have Android, iOS, and backend tickets that might get created for three independent engineers. So that's kind of our tools flow. **Matthew:* I love tools, so I always love asking. But switching gears a little bit, now that you're at this later stage in your career, with more seniority, what would be your advice for someone who comes to you and says that they want to get into Product or are just starting their first Product job?* **Corey:** The thing I would say is that a lot is expected of a product manager, especially a good one. Product management, especially at a high level, is a demanding role with significant expectations, visibility, and impact. My advice for aspiring product managers mirrors what I tell those climbing the career ladder: take your time to develop a solid foundation rather than racing up to higher and higher levels of responsibility. To be successful, you need to collect some serious skills; you need to be an exceptional Project Manager; you need strong business acumen; you need to be able to work with Engineers and demonstrate technical fluency, et cetera. I always say start there, think about all the things you're going to have to do, and find ways to do them because it's much easier at a junior level to develop those skills than at a senior level. And then from an actual entry point perspective, I always look for things that are right on the periphery. That could be Project Management types of roles, as well as a lot of Ops roles, where Ops starts taking on tasks like requirements writing for how the IVR would work or configuring how the CRM works. From there, you define some requirements, and you get into some tooling and technical writing. So there are some entry points there that I've seen work really well, and people can demonstrate PM skills. For new PMs, I know it's cliche to say, but I would say two things: You should spend as much of your time as possible with your users and invest as much of your organizational capital as you can with your Engineers. You have to have a really strong perspective on what's actually going to matter, and the only way to know that is from your users. Sometimes, you can directly talk to them, and sometimes you're in a product where that has to be done through surveys or combing through customer support tickets. It’s important not just because it helps you pick the right thing but because you need to have a ton of internal credibility when you go to bat for something or prioritize something. You only gain that credibility by having firsthand knowledge, data, and experience that you can bring when you're talking to anyone else. On the Engineering side, you are only as successful as what you ship. So you have to have a really strong partnership and relationship with your Engineers. They are not only how you succeed but also how you learn and often have better solutions to your user problems than you. **Matthew:* Yeah, that’s good stuff. Thinking back, and now this is starting to sound like a job interview, but what was one of your biggest challenges as a PM? What happened, and how did you overcome it, or what did you do to solve it?* **Corey:** I'll start with one answer, and then maybe another one will come to me that is more relevant. I’ll start with what my biggest challenge was as a Product Leader. And what I would say is that every startup that is growing and scaling is looking for people who will wear the hat that needs wearing, who will roll up their sleeves and do whatever it takes to get the job done. I'm cut from that mold, and we hire people that are cut from that mold, and a good PM is cut from that mold. You have to be; you have to wear the hat that needs wearing. At some point in time, you sort of reach a point in your growth as a company where you can’t keep living in the trenches. You have to get ahead of it and think about what the Org needs: the right structures, processes, and people in the right places. For too long, I did things that people beneath me on my team should have been doing because I was better at them, or people on my team did things because they happened to have that skill set rather than because it was their job. Unfortunately, it kept me from doing everything I needed to do, limited the growth of others, and did not set us up for efficient growth. So, as a Product Leader, one of the things I've learned and certainly failed at is getting ahead of that. Knowing when you're scaling, you have to put the right person in the right place at the right time, and that's the job. Yes, you have to be scrappy and you have to execute with what you've got, but knowing the right time to disrupt the status quo is key. **Matthew:* It's a good general management lesson, learning how and when you teach someone to fish versus handing them the fish. That can be a very tough one.* **Corey:** Exactly. I would say the thing I have failed at in Product Management time and time again, and I consistently try to improve at, is remembering that I am not always designing for myself and that I am not the user. One of my strengths is operating from first principles and envisioning a future state. That superpower can also be your kryptonite. It’s probably a cliche and what every PM book says somewhere, but I have absolutely reached that moment multiple times where I, as the user, would want this, and therefore this is the right answer. Then we actually talk to users, or we do a paper prototype or build a feature, and we find out that it’s not exactly what the users want. I need to learn to put aside how I would want to use the product. **Matthew:* That’s such a hard one; it reminds me of that saying where nobody asked Apple for an iPhone, but everyone wanted one. There’s a really interesting balance where there’s a difference, especially for Chief Product Officers, between designing new functional day-to-day product features and figuring out what the blue sky and new ideas are because users will not tell you those things. They don’t know what’s possible or what they want, and how do you identify those in such a way that you can learn whether they’re valuable from understanding user needs rather than user requests?* **Corey:** Yes, I think that is so spot on, and I also think that at a company, you are sometimes structurally set up with roles that only allow you to do one or the other, or at least encourage one type of thinking or the other. We have Product Managers who are exceptional at listening to users and building for user needs, and they run that machine super efficiently. But, it is challenging for that same person to step back and paint the vision of where we need to go three years from now, how it all comes together, and what is strategically important. So in some ways, I’ve grappled with how much long-term vision and strategic ownership you put on individual PMs. I don’t think there’s a perfect answer, but on the balance, I lean towards the thought that some of that has to come top–down. There’s just no other way that someone who is thinking day to day can be thinking about product strategy and articulate that to people. **Matthew:* This may be a little off-topic, but do you do any personality or strength assessments of your PMs?* **Corey:** Not as part of the hiring process. Afterward, though, we have done a little bit. For example, DISC is a personality assessment that we have done to see where people sit. We usually use it more within a team to figure out team dynamics and how a team can work well together to make sure we are putting them in the right seat. **Matthew:* Yeah, I think that's the right approach. You don't need ten identical PMs to solve ten slightly different problems.* *Alright, we are running a little low on time, so a couple of quick-fire questions: What are three tools, pieces of software, or methodologies that you would say to a new PM that they should learn how to do, use, or have this skill because it’s going to serve them well?* **Corey:** The first skill I would call out is to self-serve and access data, however your organization does it, so that you don’t need to go to Analytics or a BI team. It’s also helpful because you learn so much - that is where half of my technical knowledge has come from. From the analytics side, you learn the data models and the interplay between product features at a technical level when trying to dig into the data tables and build analytics or reports. So, whether that’s learning Tableau or Looker or just direct SQL queries, you should definitely learn to do that first. From a tool perspective, the one I’ve been using a ton FigJam. I don’t have a specific process for how and when to use it, but I’ve been using it a bunch. There’s something about the infinite canvas; the Product job is wide and encompasses a lot, so having something that can be high-level or granular, low-definition or high-fidelity, in one place is really effective. I have just found it really great to get the chaos in my head for a particular problem onto paper and then get people to collaborate on that. And then the other one, related to that, is if you are at the size and scale of an organization where it’s hard to get all parties you need live, I would be an advocate for asynchronous video communications. It’s just such a quick way to communicate to a bunch of different stakeholders, rather than trying to schedule a 30-minute meeting for a group of 15 people. Just record a quick video that they can then watch at 2x speed, and then boom, they’re caught up, and you’ve just saved everyone a bunch of time. **Matthew:* What’s your favorite Product Management book, blog, newsletter, or podcast?* **Corey:** ProductFTW, obviously. But I have been enjoying following the Twitter feed of the PM who is building ChatPRD. I don’t know if you’ve come across it, but I’ve been getting a kick out of her progress and her perspective on how we should inject AI into the Product process. **Matthew:* Yeah, that’s fun. We spend a lot of time as a team talking about how to use AI as a tool. Last question: What do you think the future of product management looks like? this could have something to do with AI a little bit, but how has it changed over the course of your career? What do you think is coming?* **Corey:** Product is the nexus - it’s the decision maker and the executor - and for so long, most of what you had to do was lead by influence. You don’t have direct reports; you have to marshal the troops, and you have to communicate with others. I do think a lot of the tools and technologies that are coming out that enable someone to write marketing copy or get a wireframe turned into visual designs with some AI help, or communicate something in a more technical language, I think a lot of the teams that Product relies on, Product is going to be able to get closer to high fidelity output. So I think it’s going to make the Product role more and more critical because that’s where decisions happen and where the driving force is. The task execution is what gets a little bit easier over time. I think a Product vision, roadmap, and requirements can get a lot closer to the end product a lot faster. So, the iteration cycle will be a lot quicker, as will the feedback cycle, and we will probably be able to execute with smaller team sizes and less coordination costs. At least, that’s what the optimist in me thinks is the case. How’s it changed or where has it evolved from? There’s a lot there. I think your business versus product distinction is an interesting one. I would also point to some ebb and flow I’ve seen around what role Design has, particularly UI/UX Designers versus Product Designers. Also, what role do Engineering or Tech leads have vs. what role does Product have? There are certainly effective teams that have just a Product Designer and an Engineering Lead, and there really isn’t a Product Manager, and that is all you need. Of course, there are other instances where the PM is the “CEO of the product”. I think product, design, and engineering work tightly together and each should have some of the skills of the other. For example, a good designer should have some understanding of technical feasibility and business impact; a good tech lead will have user empathy and good design taste. But at the end of the day I think that no matter your size and scale, people look around the table and are looking for someone to lead the conversation. For me, I think that any effective team needs a quarterback to start the conversation, and to drive things forward, and I look to Product to do that, and I think that has continued to be the case over time. **Matthew:* Awesome, thank you, Corey.* --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Product Talks with Dave - ProductFTW #32 URL: https://www.productftw.com/product-talks-with-dave/ Last updated: 2026-05-22T01:51:11.000Z *I’m excited to start a new series on ProductFTW we’re calling Product Talks. In this series, we’ll do one-on-one interviews with experienced product managers. Over the course of my almost 20 years in Product and startups, I’ve worked with many people whose careers have grown and matured in these roles, and I want to share their perspectives. I am learning a ton from these interviews and I hope you do, too!* *I’m talking to Dave Lifson, CPO at ClosedLoop AI for our first edition. I first met Dave when he was the founder and CEO of Postling, a social media management startup, sometime in the early 2010s.* ![](https://www.productftw.com/content/images/2024/10/Julia-s-Copy-with-Bubble--1-.png) **Matthew:* Thank you for doing this interview. Let's start with an introduction.* **Dave:** I’m Dave. I’m currently the Chief Product Officer at ClosedLoop.AI, a health tech startup in Austin. The company’s at a unique point in its lifecycle—we’re technically a Series B company, but we’re pivoting, so it feels more like a pre-product-market fit startup. It’s been fascinating working in consumer health tech and with AI. **Matthew:* What did you major in at university, and what did you think you were going to do when you grew up? Then how did you get into product?* **Dave:** I got into computers in middle school, and when I got to high school, my parents sent me to computer camp. I built my own PC by reading early how-to guides on tomshardware.com. At computer camp, I learned Basic, and then after we finished that curriculum, our teacher decided to teach us C (the programming language). By 16, I had learned JavaScript, and I wanted to be a Software Developer. I went to Cornell for undergrad, majoring in Computer Science, and completed my master’s there as well. My first job was at Amazon as a Software Developer, but I realized within the first year that all the things I really liked doing were things the product managers did. So, I transferred internally and joined as a PM on the Amazon Recommendations team. **Matthew:* Product management is a thing that can mean different things in different contexts; what does it mean to you?* **Dave:** Product management has definitely evolved. Early on, it was more that we worked with the designers and the engineers to build the best version of an idea that someone else had, so it was mostly Project Management; it felt more like a support role. Now, I think of it as being responsible for answering, “What’s the most important problem to be solving?” We are able to decide on that strategy by understanding business strategy and analytics, speaking with users and stakeholders, and understanding the competitive environment. Knowing all this will tell us what product problems we should be solving. There’s also a sort of operational layer that’s also our job, which may include things like having a tech debt that’s affecting our velocity or maybe a strategic misalignment within the company. Generally, we are the problem solvers. In that vein, I may have taken it further than other people do. I’ve given ownership over what solution we will be pursuing to my design and engineering teams. I want my PMs to figure out what the problems are, but I don’t expect them to be inventing the solutions - I turn to design and engineering to do that. **Matthew:* How do you think the role of Line PM differs from what you do now as a Chief Product Officer, if at all?* **Dave:** The core goal of finding what the most important problem to solve is stays the same, but the scope of the problem area you are looking within gets more narrow the more entry-level you are. A junior PM might focus on a small and specific problem space, whereas after a couple of years, I may tell a PM what the problem is, and they are to focus on the execution piece. As you go further up the career ladder, the problem circle gets bigger and bigger until all of a sudden it’s the entire company or industry, and then you have to find the most important problem in a way larger space. As a CPO, I’m not writing Jira tickets or handling day-to-day execution. Instead, I ensure we have the right capabilities, data, and tools we need to make the right decisions, processes, and alignment across teams to execute effectively. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Matthew:* I realize we skipped over a bit and didn’t talk about your experience very much. You don’t have to read me your resume, but can you share some highlights or interesting roles you’ve had from your career in product management, as well as the company stage or size?* **Dave:** I've worked in a variety of roles and at different company stages. I started at Amazon as a Software Developer, and while in that role, I ran a brown-bag lunch and an internal emailing list where I’d share interesting stories I read on TechCrunch. It got pretty popular, and it was actually what led to my first PM job. The Personalization Department was on the same floor as me, and they started attending the lunches as well, which is how they got to know me and made it easier for me to interview for a PM role when a position opened up. One of the companies I came across on TechCrunch was Etsy, and I thought it looked like a cool company, so I decided to cold email them asking them to hire me so I could do Recommendations for them. The founder saw my email and thought adding Recommendations was a good idea, so I flew out for an interview. I realized while I was interviewing that the PMs there didn’t know how to do product, they were more Project Managers who were taking direction straight from the CEO. Once I understood the team a little more, I changed my pitch and instead said, “Why don’t you hire me to be your first Head of Product?” In hindsight, this was pretty ridiculous because I was 25 years old and had about 9 months of professional PM experience. After about 6 months at Etsy, there was some restructuring, and I ended up leaving and starting my own company with the two engineering founders at Etsy, which we did for three years (it was called Postlink). I felt like we had built a really great product, but none of us knew anything about sales and marketing. As a Founder/CEO I should have forced myself to do those things or hire people who could, but instead, I stayed in my comfort zone of building product, and so we were never able to raise a Series A because we couldn’t prove we had scalable customer acquisition. We ended up selling the company, and General Assembly hired me. When they offered me the job, the description had nothing to do with my experience. I spoke to my mentor, and he told me that I should just get on board in whatever position they offered me if I really believed that they would be a rocket. I did believe in the company, so I took the job. Over the next two years, I worked to build up their Education Product Team and their core curriculum, then switched to Digital Product Engineering. I had a couple more years in startups, but eventually I hit a ceiling and I reached a point where I wanted to work with someone who was better at my job than I was to help me break through to the next level (I was tired of learning by failing on the job). I was able to find this at The Knot, which is a company that has had a huge impact on me. It taught me to shift my entire perspective to an outcome over outputs mentality, which opened up my eyes to how I had been living in a world of feature delivery. I was there for about 4.5 years and eventually made it to be SVP. For the last couple of years, I have been a CPO at two health-tech companies, with a year and a half in between the jobs with a very long and frustrating job search. **Matthew:* You touched on this a little bit, but can you tell us a bit more about the unique challenges of being a CPO or Head of Product in a startup where the Founder often originally thinks of themselves as the Head of Product or the visionary? How do you balance things like tooling, execution, and process versus identifying what you are actually supposed to be working on?* **Dave:** Based on my experience, I believe that a pre-product-market fit startup should not hire a CPO, and you should not try to be the CPO for that company. At these companies, they may hire a Director of Product, but you should fully expect to be hired to execute other people’s ideas, which I think is appropriate. Pre-product-market fit is all about pivoting, searching, and finding the fit. In my experience, only the founder is able to do this in a way that the company needs, because they will most likely be able to connect dots that you can’t. If you do decide to join a pre-product-market fit startup, I would say don’t even bother trying to be the CPO in this situation unless you are comfortable with an execution role, which could be great for someone in the middle of their career. Later on, the time when a CPO opportunity really shines is when they’ve found product market fit, and they are starting to scale. Here, two things start to happen: first, what used to work process-wise doesn’t work anymore because the company is a little bit bigger. Secondly, prioritization shifts from “What is the nearest dumpster fire that needs to be put out?” and gets turned into “We have a bunch of good ideas, how do we decide which of the good ideas to do first?” This is when a PM with a strength in strategy can really shine. **Matthew:* Now that you have been doing this for a while and have a bunch of different experiences, what do you tell people who come to you who either want to become product managers or are in their first couple of years of product? What is your number one piece of advice?* **Dave:** Entry-level PM jobs don’t really exist, so I would say that the way to get an entry-level opportunity is to transfer internally. Don’t try to apply to entry-level jobs externally; join a company where you have some unique skillset (like a subject matter or expertise). If you do have an opportunity to join a company as a junior PM, don’t join a startup; the smallest I would go is a company that has around 10 PMs, which is a pretty big company. You’re going to need a lot of help, and if your manager is the only person you can turn to for help or to ask questions, I don’t think that you will get the support that you need. You want a senior person who is your peer, who can also be your mentor. When companies are smaller than 10 PMs, everyone is going to be at maximum capacity with their own workload, and they won’t have time to help you in the way that you need. **Matthew:* Are there any go-to books, newsletters, or podcasts that you recommend to people who are trying to grow their skills? Other than your own.* **Dave:** Other than[ my own](https://lessons-learned.beehiiv.com/subscribe?ref=productftw.com), I always recommend Ben Thompson’s newsletter, [Stratechery](https://stratechery.com/?ref=productftw.com). I’ve been a subscriber for over 7 years now. In addition, I would also recommend[ Lenny’s Newsletter](https://www.lennysnewsletter.com/?ref=productftw.com),[ Marty Cagen](https://www.svpg.com/team/marty-cagan/?ref=productftw.com) and[ Teresa Torres](https://www.producttalk.org/?ref=productftw.com). I have also heard from a lot of people that the [Reforge](https://www.reforge.com/?ref=productftw.com) resources are very good, but I haven’t used them myself. **Matthew:* I think you’ve already touched on part of the answer to this question when you were talking about The Knot, but what do you think is one of the biggest lessons you’ve learned as a PM that changed the way you work or even more fundamentally, the way you think about building product?* **Dave:** We talked about outcomes over outputs a little bit - it used to be the case where I felt like I was constantly under pressure from my Founder to ship the roadmap faster. It was all about getting good at estimating ship dates and velocity, and we would inevitably miss our dates, then we felt like we were bad at our jobs because we missed the dates. As soon as we shipped something, we immediately moved to the next thing on the roadmap because there was so much to build and we had to constantly be building. At The Knot, it shifted to become more of, “What are the outcomes that we're trying to achieve as a company?” Which was usually measured in terms of metrics and KPIs. Then, the teams were free to go and do whatever they needed to do, as long as the KPIs were going up. I no longer agree with that methodology either, but that was the first time where I felt like I was doing something really different. It was great because it gave the team a lot of autonomy to go and try a bunch of stuff, but the problem was that there was no strategy that tied all of the work together. Everyone was just focusing on optimizing their corner of the product, but nothing was stitching all of the pieces together into a bigger opportunity. We continued to build on that approach, though, and we soon decided that just going after the same KPIs each quarter (and making sure the numbers were going up) wasn’t a great idea, and we ended up developing a more strategic approach with a thread that drew everything together. **Matthew:* If you came into an organization as Head of Product and you could snap your fingers and set the tooling set and the methodology for development that you’d use, what would your go-to or favorite set of tools and processes be?* **Dave:** In terms of software tools, I’m not really a tools guy, I will just use whatever the team prefers. Some of my ambivalence towards tools comes from when I was first learning to be a PM at Amazon, where we used Excel to manage our backlog because all these tools didn’t exist in 2007\. Something very important to me is that the PMs use a product brief. The product brief, for me, is not a product requirements document but more a document outlining what the problem is we are trying to solve, what metrics we’ve used to measure success, what our hypotheses are for what is going on, and what underlying assumptions must be true in order for our hypothesis to be true. I like to take those assumptions and then have the team figure out how to validate and de-risk them. The enemy that I am always trying to fight is the desire to just build the whole thing, ship it, and then find out if we were right or wrong. I try to pull forward the eventuality that we may fail while we make investments rather than after the fact. We have started looking at [greatquestion.co](http://greatquestion.co/?ref=productftw.com) as a user research platform, they have an integration with [respondent.io](http://respondent.io/?ref=productftw.com) for recruiting user participants, and it seems like a useful tool for us so far. We’re also using [MixPanel](https://mixpanel.com/?ref=productftw.com) right now for funnel analysis. My advice would be to always have a BI tool, even if it’s just MetaBase (which is free), a funnel analysis tool, a user research platform tool, and hopefully connect all of your data in one place. **Matthew:* What’s the most rewarding thing about being a product manager for you?* **Dave:** So I'm going to first tell you a little bit of a story, and then I'll give you an answer. Last year, I was working with a founder as a consultant, and she brought in her executive coach. In our first meeting, it was like a two-on-one. It was almost like a couples therapy session. And so this coach asked the both of us, the founder and then myself, “What are your short-term goals for working together, and what are your long-term goals?” And for me, and this is the answer to your question, the long-term goal for me is that I just want to make a difference; I want to have an impact. I want people to have a richer experience in their lives in some kind of way. This is why I've never really worked on Enterprise SaaS B2B software. It doesn't deliver enough reward to the user to satisfy me. The founder's answer was she wanted to be on the cover of every magazine; she wanted everyone to know who she was. And that goes to show just how much of a difference between the personality type of some founders and then product. So I guess my answer is, I just want to make a difference and make an impact. **Matthew:* What do you think the future looks like, and how has product changed in the time you’ve been doing it professionally?* **Dave:** Okay, so I don't know if we could have spent an entire session on this question because my day-to-day now is building a product on top of an LLM. It is fascinating how different it is in terms of the product development process. And what I mean by that is, up until now, my entire career, product has been something where on the day you start, there is zero functionality, and so your product can do nothing. Then you think about all the use cases and the user journey, and then you build all these different screens and features, and you lead people down these funnels that you create for them that get them from start to finish. In an LLM world, out of the box on day one, it can handle infinite input and give back infinite output. It’s of unknown quality, accuracy, and trustworthiness, but it will answer every question. From these infinite use cases and capabilities, you then need to shrink it all the way back down to whatever you think the product-market fit is and then scale from there. And so instead of this, like, zero to one to 100 progression, it's like infinity to one to one hundred. And it's bonkers. It's really, really fun. But it's so much more about immersion design and trying to be adaptive to how your users will use your product in ways that you never thought of. It's a really interesting time. ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Talks*](https://www.productftw.com/product-talks/) *series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.* ### Product Debt - ProductFTW #31 URL: https://www.productftw.com/productftw-31-product-debt/ Last updated: 2026-05-19T19:22:18.000Z ![Image of a brick wall with the words "until debt tear us apart" painted](https://www.productftw.com/content/images/2024/09/alice-pasqual-Olki5QpHxts-unsplash-1.jpg) Photo by [Alice Pasqual](https://unsplash.com/@stri%5Fkhedonia?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) In the product world, we hear a lot about technical debt, but have you ever heard of product debt? These two concepts are often tied together, but not all technical debt is product debt, and not all product debt is technical. Both, however, have the same outcome: they slow down future development. ## So what is product debt? Product debt is the accumulation of decisions you’ve made as a product leader that, over time, start to degrade the user experience or cause friction in the product. Now, you might be thinking, “Wait, what? I make decisions every day, that doesn’t mean they’ll eventually degrade the user experience.” But here’s the catch: they could, especially if you’re not keeping track of UX trends, what competitors are doing, or what’s happening in the industry. Here are a few common examples of product debt: - **Feature bloat:** Continuously adding features without removing unnecessary or outdated ones. - **Unaddressed UX issues:** Prioritizing other features above fixing strange or frustrating user experiences. - **Outdated decisions:** Failing to revisit decisions to ensure they’re still relevant and helpful. - **Unnecessary customizations:** Making one-off tweaks for a specific user or customer that don’t benefit the broader user base. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Why does product debt matter? When I joined a small cybersecurity startup, I inherited a B2B portal where companies could upload data to monitor across the dark web. It was one of the first self-service tools in the space, and the company had moved fast to get it out there. But that speed came at a cost: they hadn’t spent much time thinking about the user experience. The result was a confusing product. Other startups in the space were growing quickly and outpacing us, not because they had better features but because their tools were easier to use. Despite having the same capabilities, we were losing customers because our product was harder for them to navigate. Product debt doesn’t just hurt you financially. Like tech debt, it can slow you down. Every time you build new features, you’ll have to work around those unaddressed items, or worse, you’ll have to build them into the new features. If you don’t tackle it early, product debt will come back to haunt you. ## How to address product debt So, how do you tackle product debt before it takes over? Here are a few steps to help you keep things under control: **Audit your product** Regularly review your product to identify areas where debt has accumulated. This might involve usability testing, looking at analytics, or just stepping back and using the product from the perspective of a new user. Where are users getting stuck? Where have you added features that no one uses? Find those areas and start making plans to address them. **Prioritize debt reduction** Similar to how you prioritize reducing technical debt, you must actively work on reducing product debt. Add specific tasks to your roadmap dedicated to fixing these issues. Whether it’s simplifying workflows, revisiting old decisions, or removing unnecessary features, you’ve got to make time for debt reduction in your sprints. **User-centered cleanups** When cleaning up product debt, involving your users is a good idea. Talk to your customers, gather feedback, and see where they’re experiencing frustration. The things that seem small to you are often the most painful for your users. Fixing those seemingly minor issues can have a huge impact on overall satisfaction. **Revisit decisions and assumptions** The decisions you made when launching the product might not hold up over time. Make it a habit to revisit these assumptions regularly. Are your features still solving the right problems? Is the user flow still aligned with modern UX standards? Is the market shifting in a way that should change your priorities? A product is never “done,” the more you adapt and evolve, the better. ## The cost of ignoring product debt Ignoring product debt isn’t really an option if you want to build something sustainable. The longer you leave it, the more it compounds. Features become harder to implement, user churn increases, and your product falls behind the competition. In my case, ignoring those UX issues in the cybersecurity startup didn’t just slow us down; it allowed our competitors to outpace us. While we struggled with an increasingly confusing product, they focused on ease of use, and today, they’re still thriving. We ended up taking an exit, but I can’t help but think that if we had addressed our product debt earlier, things might have gone differently. Product debt is a silent killer in the product world. It sneaks up on you, and if you’re not careful, it can seriously hurt your product’s chances of success. The good news is that it’s manageable. By regularly auditing your product, involving users in cleanup efforts, and revisiting past decisions, you can keep product debt in check and ensure your product continues to thrive. So, the next time you plan your roadmap, make sure you carve out time to tackle product debt. Your users (and your future self) will thank you for it. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Starting a Startup with Friends - ProductFTW #30 URL: https://www.productftw.com/productftw-30-starting-a-startup-with-friends-lessons-from-my-journey-with-sherpio-and-beyond/ Last updated: 2026-05-10T23:40:13.000Z At ProductFTW, we spend a lot of time discussing product management and the art of being a product manager. As a product manager, you're a decision-maker, constantly balancing building great products and being accountable to others, like C-level executives, board members, or founders. It's a challenging role, but you're operating within the safety net of an established organization, with the guardrails of existing processes and the comfort of shared responsibility. However, many product-minded people often dream of stepping out of this role and starting their own company. The thought of becoming independent, setting your own vision, and creating something from scratch is incredibly appealing. But it can also be terrifying. Suddenly, all the risk and responsibility falls on you. This fear might drive you to seek a co-founder, and who better than a friend or a spouse, someone you already trust and share a connection with? ![Image of Ellen, Mitchell, and Zach](https://www.productftw.com/content/images/2024/09/IMG_0080.jpg) The old Sherpio crew I've taken the leap twice, and both experiences taught me valuable lessons about the dynamics of co-founding a startup, particularly when it comes to the risks of working with co-founders who aren't fully aligned or invested. There are pitfalls to watch out for: differences in commitment, overlapping responsibilities, time management conflicts, and the inevitable slow decision-making that can drag a startup down. Let me start with my experience at Sherpio. I co-founded Sherpio with Zach and Mitchell, two friends who brought distinct skills to the table. Zach was incredibly committed from the outset; he quit his full-time job and poured all his energy into the startup. Mitchell, who handled the development of our product, was exceptionally talented and contributed significantly, but since we never openly discussed his level of commitment or personal struggles, I'll focus on the dynamic between Zach and me. While Zach was fully invested, I was in a different place. My natural risk aversion made it hard for me to leave my full-time job, so I tried to balance my regular work with my responsibilities at Sherpio. This decision set the stage for many challenges. Zach was pushing hard, working long hours and weekends, while I was juggling Sherpio with my other commitments. I'm sure Zach felt frustrated like he was carrying the weight of the startup while I held back, unable to match his level of dedication. Our overlapping skills only made things worse. Both Zach and I had experience in product development and strategy, but there needed to be a clearer understanding of who should lead specific tasks. This overlap led to confusion and slow decision-making, a deadly combination for any startup. Every decision turned into a debate, every task became a shared responsibility, and our progress slowed to a crawl. It became evident that the structure we had in place wasn't conducive to the speed and agility needed to succeed. In the end, I left, deciding my lack of commitment was holding back the team and Zach and Mitchell continued on without me. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. In contrast, my recent experience starting a new venture with my husband has been entirely different. This time, we both dove in with equal commitment. I handle the creative side, business decisions, scheduling, and overall operations, while my husband, who has no background in business, takes care of the physical work. We each bring different skills to the table, and there's no overlap. This clear division of roles has allowed us to move fast, make decisions efficiently, and avoid stepping on each other's toes. Now, I am not under any illusions that starting a business with my spouse is an objectively good idea. I've read somewhere that it's considered a relationship killer, and I understand why. Running a business together comes with its own set of risks, including the potential strain it can put on a marriage. However, we both believe that our clear division of responsibilities and complementary skills will lead to success, and we're willing to take the risk. We're aligned in our goals, we communicate openly, and we trust each other to handle our respective areas. These factors have been crucial in keeping things smooth so far. Reflecting on these two experiences, I realized that having multiple co-founders isn't always the best approach. While having co-founders might seem appealing for sharing the workload (emotionally or physically), it can actually create challenges that hinder progress. Startups often benefit more from having a single decision-maker who is fully bought in, someone who can set the vision and motivate the team. If everyone is a co-founder with overlapping skills, every decision becomes a drawn-out debate, drastically slowing you down. I've also learned that hiring people committed to the company's future potential, either through equity or compensation, can sometimes be a better strategy than bringing on multiple co-founders. With employees, the expectations are clear: they know their role, the boundaries of their involvement, and what they stand to gain. This clarity can create a more streamlined path to progress, avoiding the paralysis that comes from too many voices in the decision-making process. Speed and decisiveness are critical to a startup's success. At Sherpio, our differing levels of commitment and overlapping skills led to slow decision-making, which dragged down our momentum. On the other hand, in my new venture with my husband, decisions are made quickly because we trust each other's judgment in our respective areas. There's no second-guessing, no debates, just swift, confident action. This agility makes all the difference. The more I reflect on these two experiences, the more I see the importance of having one person who is fully committed and ready to lead. Complementary roles, quick decision-making, and a shared commitment to the vision are what truly drive a startup forward. While it may feel safer to start a business with friends or loved ones to share the burden, it might be better to go at it alone or partner with someone as committed as you are, but with an entirely different skill set. The fear of taking on all the risk and responsibility by yourself can be daunting, but it's often better than dealing with the challenges that come with co-founders who aren't fully aligned. If you're considering starting a startup with friends or loved ones, take a moment to consider the dynamics carefully. Make sure everyone knows their role, their commitment, and their place in the decision-making process. Most importantly, ensure that you have one person, whether it's you or a trusted partner, who is ready to take charge, lead with clarity, and motivate the rest of the team. In the end, it's not about how many co-founders you have, but about how effectively you can move forward together. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### The Product Brief - ProductFTW #29 URL: https://www.productftw.com/productftw-29-the-product-brief/ Last updated: 2026-05-22T02:26:19.000Z Have you ever lost alignment with your engineering team or struggled to get everyone on the same page? Whenever I felt this way, it was likely because I rushed through the Product Development Lifecycle (PDLC) to deliver requirements to my team as quickly as possible. Although well-intentioned, skipping steps in the PDLC can lead to misalignment and confusion. The PDLC exists for a reason, and a core part of its value lies in the artifacts you create along the way. These artifacts help get buy-in from the team, create alignment, and ensure that what you ultimately deliver is the correct solution for your user. The product brief is one artifact that doesn’t always get the attention it deserves. ![Image from ChatGPT of a product brief template.](https://www.productftw.com/content/images/2024/08/product-brief.png) It seems like someone needs to use spellcheck... ## What is a Product Brief? A product brief, also known as a product proposal, is a concise (usually less than one page) strategic document created in the earliest stages of the PDLC: the strategy phase. It outlines the key elements of a potential project and, unlike more detailed documents like the product requirements document (PRD), a product brief focuses on high-level alignment and sets the stage for deeper exploration and validation. Essentially, it’s about putting your hypothesis on paper for the team to assess and determine if it’s worth pursuing. ## Product Brief Outline While there isn’t a set template for a product brief, as every product manager has their own style of communication, at its core, a product brief should generally include the following sections: 1. **Summary**: A high-level overview of the project, including a hypothesis that outlines what you plan to do and why. 2. **Problem Statement**: A clear articulation of the problem you aim to solve and the audience it affects. 3. **Project Objective & Business KPI(s)**: Specific objectives for the project and the key performance indicators that will measure success. 4. **Company Goal Alignment**: How the project aligns with the broader goals of the company. 5. **Data Summary**: Initial evidence supporting the importance of solving the problem, such as research or analytics. 6. **Success Criteria**: The metrics or outcomes that will indicate whether the problem has been effectively addressed. ## Why is a Product Brief Important? The product brief is important for several reasons: 1. **Early-Stage Alignment:** At the beginning of a project, teams face a lot of uncertainty. The product brief helps align everyone by clearly articulating the problem, the proposed solution, and the initiative's goals. This alignment is crucial for ensuring that everyone is on the same page before moving forward. 2. **Guiding Strategic Decisions:** The product brief serves as a strategic tool to help guide decision-making in the early stages of development. It provides a framework for evaluating whether a project is worth pursuing based on the hypothesis and supporting data. 3. **Setting Expectations:** The product brief outlines the project's objectives, KPIs, and success criteria, setting clear expectations. This clarity helps prevent scope creep and ensures that the team remains focused on the most important outcomes. 4. **Efficient Communication:** The product brief is a highly effective communication tool. It distills complex ideas into a concise format that is easy for everyone to understand and discuss. This is especially important when dealing with cross-functional teams with different perspectives on the project. ## How is a Product Brief Used in the PDLC? I’ve mentioned the PDLC a few times. The product brief is used during the strategy phase to establish a strong foundation for the project. However, this doesn’t mean you’ll create the artifact and then immediately discard it once you move to the other stages of the lifecycle. The product brief is actually used and built upon during every stage of the PDLC: - **Strategy Phase:** The product brief is created during the strategy phase, where the team explores different ideas and concepts. This document helps narrow the focus to a specific problem and solution that aligns with the company’s goals. - **Discovery Phase:** Once the product brief is approved, the project moves into the discovery phase, where the initial hypothesis is validated through research, prototyping, and user testing. The brief serves as a reference point during this phase, ensuring that the team remains aligned with the original objectives. This is typically when the brief starts to evolve into the beginnings of the PRD. - **Development Phase:** As the project progresses into development, the product brief continues to evolve as the guiding document. It provides the context and rationale behind the project, helping the team make informed decisions as they encounter new challenges and opportunities. - **Launch and Post-Launch Phases:** The product brief remains relevant even after the product is launched. It should be used to evaluate the project's success based on the KPIs and success criteria defined in the brief. Additionally, it serves as a historical document that can inform future projects. As the product brief evolves, it is important to keep an intact version to show the evolution of the project and findings. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## How to Compile a Product Brief Now that we have a solid foundation of what a product brief is and why it matters let’s discuss how to actually create one using the outline referenced above with examples for each. ### Summary The summary is the foundation of your product brief. This section should provide a high-level overview of the entire document and include a well-crafted hypothesis. If you don’t remember the formula for a hypothesis (I immediately forgot this after high school), here is the outline I use: > *By \[doing this thing/building this feature/creating this experience/building this solution\] for \[this user/customer segment/customer profile\], we will achieve \[this business outcome\] and solve \[this user problem/this gap in the market\]. We will measure this by seeing \[this quantitative/qualitative outcome\].* Then, apply that formula to your product. Example: > *By offering a consumer credit card that rewards points on rent payments for young professionals, we will increase card adoption and usage while solving the challenge of low-value transactions among this segment. We will measure this by seeing a 25% increase in monthly active users and a 15% increase in average transaction value.* The summary should also briefly touch on the key points that will be covered in the rest of the brief, such as the problem being addressed, the objectives, how the project aligns with company goals, and the success metrics that will be used to measure outcomes. ### Problem Statement The problem statement clearly outlines the specific issue that your product is designed to solve. This section is important because it focuses your team’s efforts on addressing a real and significant challenge that impacts your target audience. > *Young professionals often struggle to earn rewards on their largest recurring expense: rent. This leads to lower credit card usage among renters, reducing their engagement with credit products.* The problem statement should identify who this problem affects and why it’s important to address it. ### Objective & Business KPIs Once the problem is clear, the next step is to outline what you aim to achieve with this project and how you will measure success. The project objective should be specific and aligned with solving the identified problem. KPIs (Key Performance Indicators) are crucial for tracking the progress of your project and ensuring that it meets its goals. > *Objective: Increase card adoption and usage among renters by offering rewards on rent payments.* > *KPIs: A 25% increase in monthly active users and a 15% increase in average transaction value.* This section directly connects the objectives and KPIs to the project’s success, providing measurable outcomes guiding the team’s efforts. ### Company Goal Your project should support broader company objectives. This section ensures that your project is not just solving a problem but also contributing to the business's overall success. Aligning your project with company goals shows how it fits into the bigger picture. > *If the company’s goal is to expand its market share among young professionals, this project’s objective of increasing credit card adoption among renters directly supports this by attracting a key demographic.* This alignment demonstrates the strategic importance of the project and its role in driving overall company growth. ### Data To strengthen your brief, include data supporting this project's need. Data provides evidence that your problem is real and that your proposed solution is viable. This can include market research, user feedback, or any other relevant data points. Example: > *Market research shows that 70% of young professionals rent their homes, and 80% would be interested in a credit card that offers rewards on rent payments.* Presenting this data validates the problem and justifies the need for your proposed solution. ### Success Finally, outline how you will measure the project's success. Success criteria should be tied directly to your KPIs and clearly indicate whether the project has achieved its objectives. This section is crucial for ensuring that everyone understands what success looks like for the project. > *Success will be measured by a 25% increase in rent payments made with the card and a 15% increase in average transaction value.* Defining success in measurable terms allows you to track progress and determine if the project delivers the expected outcomes. ## Putting It All Together Compiling a product brief is about clarity, alignment, and evidence. Each section should build on the last, creating a cohesive narrative that clearly articulates the problem, the proposed solution, and the expected outcomes. By following this guide, you’ll ensure that your product brief is a powerful tool for early-stage alignment, setting your project up for success as it progresses through the development lifecycle. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### The Product Development Organization of the Future - ProductFTW #28 URL: https://www.productftw.com/productftw-28-the-product-development-organization-of-the-future/ Last updated: 2026-05-10T23:40:11.000Z ![Abstract geometric shapes in vibrant red and orange hues, creating a dynamic and energetic composition that conveys a sense of innovation and creativity.](https://www.productftw.com/content/images/2024/08/DALL-E-2024-08-07-09.46.09---A-vibrant-and-dynamic-image-representing-innovation-in-product-development.-The-composition-features-abstract-geometric-shapes-and-patterns-in-bold-re.png) Yes, we're going to discuss AI There are two unmistakable trends that are disrupting how we think about product development in the current market: 1. The end of “Zero Interest Rate Percentage” (ZIRP) financing is forcing companies at all stages to deliver more value with fewer resources (particularly software engineers). 2. The development tools leveraged inside and outside of traditional ‘code’ are growing increasingly more sophisticated, and it’s not just AI. These trends will have a harmonic rather than dissonant effect on how we think about accelerating the process of designing, delivering, and measuring good product outcomes. However, it will require a change of mindset from both leadership and individual contributors alike when it comes to how teams collaborate and use the new tools. ## **Improve the Tools, Don’t Resist Them** If you’re finding the current moment intimidating, you’re not alone. I could barely use ChatGPT, even months after every other post on LinkedIn was telling me I’d be left behind if I didn’t use the latest 10 AI apps that had popped up in the previous week. You’d also be correct in assessing many of these offerings as ‘not ready for prime time’ when it comes to a serious production application rather than individual tasks. That said, the change is real and we should embrace it. After all, the same things were said about the cloud rather than physical data centers, and real-time business intelligence tools rather than offline spreadsheets. Nobody wants to go back to the days of needing to shrink wrap software onto packages of floppy disks and distribute in stores for a “release” rather than continuous deployment. Remember, this current wave of Large Language Models (LLMs) is nothing more than better data management to enable complex content generation. It’s a progression on what has been possible with Software-as-a-Service e.g. CMS, CRM, and A/B testing platforms – all of which product teams have come to embrace over the past decade. This content can also include source code generation itself, and several tools are emerging that sophisticated engineers and product managers can integrate to “test and learn” new customer-facing features without writing any new code at all! ## **Consider the T-shaped Team as a Convergence of Skillsets** The concept of “T-shaped” means someone with a good combination of generalist skillsets and one deep specialism. This has already manifested itself in advocacy for a “product engineer” as a developer who owns large parts of design and outcomes rather than just code, and [Zach’s previous discussion of how technical a PM should be](https://www.productftw.com/productftw-18-should-product-managers-be-technical/). The rise of these new tools combined with the fall of engineering capacity is a perfect storm on which to practice these ideas. It doesn’t mean PM and developer roles should no longer exist, but there’s an emerging case that each cross-functional team could have an equal ratio across design, developer, data, and PM specialists with T-shaped skills allowing pairing or any two roles to either build a new component or redeploy existing ones via prompt, component, or data engineering. Putting this into more explicit practice, the team of the future could very much look like this: - Product T: manages stakeholders, deploys features, prototypes new components - Engineering T: hardens new components, manages architecture, orchestrates data flows - Data T: manages data pipelines, language model tuning, and BI reporting - Design T: generates assets, conducts research, runs tests using prompt tools Each of these roles will need to be proficient at prompt ‘toolchains’ across multiple domains. Consider that just these four roles could cover the product remit that might have taken a dozen roles across multiple teams to do just five years ago! ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **Advice for Ambitious Product Leads** Just as engineers aren’t expected to know assembly language to develop good features anymore, we are entering a world where product and design roles won’t need to know code in order to develop these same features. That said, everyone needs to understand enough about ‘how things work’ to produce good outputs from these tools that will lead to good outcomes. If you’re the PM on a team, it may mean you are increasingly in charge of the customer journey, feature development, and deployment from a set of engineering-managed components and integrated prompting tools. I highly recommend that everyone in a product role learn Prompt Engineering to generate production assets (code, designs, APIs, modules, etc.) in collaboration with their data and engineering peers. As with the future teams described above, Leadership roles will also become more T-shaped. The current debate about “Chief Product and Technology Officer” may well become moot as this role, alongside traditional CIO and Data roles, converges on a “Chief Digital Officer.” In many ways, everything old is new again, even if the methods and capabilities increase with each generation! ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Offshore Dev Teams and Startups - ProductFTW #27 URL: https://www.productftw.com/productftw-27-opinion-offshore-dev-teams-and-startups/ Last updated: 2026-05-10T23:40:09.000Z As a strong advocate for remote work, it might surprise you to learn that I was initially skeptical about collaborating with offshore teams as a product manager. My early experiences at large companies were less than favorable, filled with communication challenges, wildly different working hours, and a terrible handover process that brought projects to a standstill whenever any detail was missing. When I transitioned into the startup world, I believed that offshore collaboration required a level of detail, planning, and certainty for success, which was simply unrealistic for the often chaotic environment of a startup. ![Image of Ellen sitting at a conference table having a LAN party playing StarCraft.](https://www.productftw.com/content/images/2024/07/IMG_0966.JPG) A #TBT of Ellen hard at work (for any young people - this is known as a LAN party) However, my perspective shifted when I had the opportunity to work with an offshore team led by an onshore manager, and the experience far exceeded my expectations. This was the most significant factor for success that I’ve noticed throughout my experiences. Having someone who shares similar working hours, understands the cultural work nuances between both teams, and typically speaks both languages is incredibly important. They act as a technical lead but can also assist with project management. They ensure that the requirements and use cases are thoroughly understood because they can see your perspective and translate it into terms the offshore team can grasp, even when certain business concepts do not exist in the offshore team's region. My first experience collaborating with an offshore team at a startup was during a particularly challenging time. We were struggling financially to keep the business afloat, trying to sell our product while seeking acquisition opportunities. Despite having clients, we couldn’t afford to continue operations. The financial situation forced us to lower our costs by eliminating full-time employees and turning to outsourcing as a solution. Losing subject matter experts and friends was hard, but this pivotal decision helped us sustain the business until we found a suitable merger opportunity. 💡 Do you love ProductFTW? Share or forward this post to a friend! OK, you don't have to ****love** it; you could just find it sort-of interesting. Either way, you should share it. ### **Finding the Right Partners** One key realization during this time was the importance of carefully evaluating potential offshore partners and looking for those with a portfolio of startups they’ve collaborated with or who are startups themselves. These types of partners recognize that startups operate in a fast-paced, fluid environment where priorities can shift rapidly, and the ability to adapt and respond quickly is crucial. These startup-savvy offshore teams are accustomed to working with limited resources, tight deadlines, and evolving requirements, making them far more adaptable and responsive than I had initially given them credit for. It's essential to recognize that offshore teams are not a one-size-fits-all solution. They won't be able to handle every aspect of your project, and that's not what you're paying them for. This approach is not a shortcut but a practical way to start piecing together the product that you will ultimately own and manage with your in-house technology team. Expect gaps and be prepared to invest in solving them. Remember, you're not paying the offshore team to be experts in your specific domain or solve every problem; you're paying them to execute based on your guidance. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ### **Overcoming Communication Barriers** Contrary to my initial concerns, language barriers, and communication challenges proved to be less of an issue than anticipated. While not everyone needs to speak perfect English, having a reliable intermediary who can facilitate communication and ensure both sides are always on the same page is crucial. Another component of success is effective project management on both ends. The use of collaboration tools like Trello and Slack, along with regular video conferences, helps bridge the physical distance and keep everyone aligned with project goals and timelines. This is an area where you need to be more intentional because of timezone differences or because your offshore team is not domain experts, but if you have a reliable counterpart or manager, good project management goes a long way toward successful and on-time delivery. ### **Cost Benefits & Ongoing Advocacy** The cost benefits are significant, and when managed correctly, the collaboration can be just as effective, if not more so, than working with an onshore team. Of course, the decision depends on your product's specific goals and technology, but more often than not, starting with a contracting model makes a lot of sense. In my current role as a consultant, I continue to work frequently with offshore teams. My positive experiences with them have reinforced my belief in their value. My initial skepticism has turned into a strong advocacy for offshore teams. The experience has been overwhelmingly positive, proving that with the right partner, approach, and tools, these collaborations can be highly successful and beneficial for startups. ### **Lessons Learned** Looking back, I realize that my journey with offshore teams has taught me several lessons. First, having an onshore manager who shares similar working hours, understands cultural nuances, and speaks both languages is essential. This person ensures that requirements and use cases are thoroughly understood and effectively communicated. Next, having flexible and adaptable partners is a must in a startup environment. Offshore collaboration requires a willingness to pivot and adjust plans as circumstances change. Implementing effective communication and project management tools to bridge gaps and ensure smooth operations is crucial. Using the right tools and maintaining regular communication can make a significant difference. Finally, leveraging the strengths of your offshore team while being mindful of their limitations helps create a balanced and productive working relationship. Recognizing that they are there to execute based on your guidance will set the stage for success. ✉️ Share ProductFTW with friends and colleagues. Just forward it! ### About ProductFTW ProductFTW is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Driving Engagement - ProductFTW #26 URL: https://www.productftw.com/productftw-26-driving-engagement/ Last updated: 2026-05-19T19:22:17.000Z Last week, in [ProductFTW #25](https://www.productftw.com/productftw-25-user-problems/), I discussed the importance of clearly defining your user’s problem before developing a solution. It sounds obvious, but so many product managers and developers first focus on a cool solution before they can clearly define a user’s problem. This week, I want to discuss articulating a user's problem in a way that drives your user to purchase or adopt your product. To illustrate this concept, we’re going to talk about sales. Many product managers shy away from talking about sales, feeling like that is someone else’s job. For many years, I didn’t think of myself as being a sales-y person or being able to sell things, even though I had sold many products and services over the years. Influencing others is a key capability for a successful product manager, so don’t skip this post! ![Image of a man at a coffee shop on his laptop. Photo by LinkedIn Sales Solutions on Unsplash.](https://www.productftw.com/content/images/2024/07/pftw26-1.jpg) Not a real photo of Matthew. He always drinks iced coffee. In 2019, I started Vertical Finance to build credit cards with rewards programs that connect groups of passionate users with small merchants. We planned to build a merchant network of hundreds of great merchants that would be a compelling counterpoint to traditional co-brand cards focused on large corporations (e.g., the United Airlines credit card). Our first (and only) product was the Grand Reserve World Mastercard, which focused on wine enthusiasts. Our cardholders would earn 5x points per dollar at interesting, high-quality wineries, which meant we needed wineries. 💡 Do you love ProductFTW? Share or forward this post to a friend! OK, you don't have to ****love** it; you could just find it sort-of interesting. Either way, you should share it. I embarked on a nine-month cold outreach sales campaign to build this network. While the logistics of cold outreach are the subject of some other blog post, the sales message that I developed illustrates how a problem and solution and its framing change folks' interest in it. At its most basic level, the problem we thought we were solving for wineries was pretty basic: to sell more wine. We would build a loyalty program that would allow us privileged access to market wineries to our users, combined with a built-in rewards incentive for buying from our partners. My first outreach was basically: “Do you want to sell more wine? We can help.” The message didn’t work. I had some conversations with winery owners and learned through trial and error that the wineries don’t view every customer as equivalent, and not all revenue is equal. Selling a single bottle of wine to a customer is good in the sense of new revenue but not great in that it’s just one bottle of wine. Attracting someone to a tasting who doesn’t buy lots of wine is not good and maybe money-losing. The priority business goal for the winery owners was to acquire new winery club subscribers. Wine club subscribers enter into a relationship with the winery and commit to buying a minimum amount of wine, enabling the winery to plan better and have dependable income. These users also engage more deeply with the winery, visiting it, introducing their friends to the wine, and more. The problem wasn’t “I need more revenue.” It was “I need more wine club subscribers.” We surveyed our loyalty users and discovered that 83% of them belonged to a winery-direct wine club. I changed my message to something like: “You want more wine club members. We can help. 83% of our members belong to at least one wine club. Do you want access to them?” ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. The results were a dramatic improvement in engagement and sales. Over the course of the company, we built a merchant network of more than 450 wineries. The product wasn’t really different: it was still a marketing and loyalty platform to connect wine enthusiasts to wineries. However, the solution's positioning differed, and the wineries desired to engage with us. (As a side note, these tactics didn’t work with wine stores, probably for the same reason of having the wrong problem statement.) When you are thinking about what to build and how to make your product successful (you have to sell it or create engagement), you must consider the core and specific problem. Generic offers like “make more money” aren’t enough. You must go deeper to find the underlying problem statement, enabling you to make your solution a must-have. 💌 Share ProductFTW with friends and colleagues. Just forward it! ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### User Problems - ProductFTW #25 URL: https://www.productftw.com/productftw-25-user-problems/ Last updated: 2026-05-22T02:26:14.000Z Understanding the user's problem is the most crucial part of the job for product managers. It sounds easy, but clearly understanding and defining a problem is a huge challenge. Product managers need to identify problems and prioritize them. This ability to identify and prioritize enables a product manager and a design and engineering team to build a solution to each problem. Unfortunately, what I see and what I hear most of the time is that product managers focus on two things instead: 1. the product manager's problems 2. a cool solution ![Image of a woman thinking with a text bubble that contains "user problems"](https://www.productftw.com/content/images/2024/07/user-problems.png) ✉️ Do you love ProductFTW? Share or forward this post to a friend! ## The product manager's problems Because product managers are trying to build products that users love and, most importantly, are willing to pay for (be it by engaging with advertisements or, better yet, paying for value delivered), it is critical that she is focused on what her users need and what problems they have. This requires empathy on her behalf for her users’ problems. In an idealized world, a product manager would be solving for a group of users just like her, in which she is the user and understands everything. This situation is very rare. It sometimes happens for entrepreneurs who have the luxury of hiring themselves to solve their problems. My previous company, Wallaby, was an example of this. However, in the real world, most product managers are doing a job and are not explicitly solving a problem that applies directly to themselves. I see product managers attempting to mangle the problem into a problem that matters to them and that they can solve. For example, at Wallaby, we primarily focused on helping a user focus on maximizing credit card rewards. These users typically did not carry credit card balances and did not care about that problem. That said, more people in the country carry a credit card balance, and solving this is a tempting idea. It serves many users, and many product managers, including some who worked for me at Wallaby, wanted to pursue this. It wasn't our goal, nor was it our user. If we had tried to solve that problem, we would have ignored our users' problems and instead focused on our (the product manager's) own problems. ## A cool solution ![Image of a woman running away from a computer with a text bubble containing "Cool Solution"](https://www.productftw.com/content/images/2024/07/cool-solution.png) The second standard error that product managers make is to focus on a solution without regard for whether a problem exists at all. This approach is backward product management, but sometimes it works out OK. For example, you might imagine a cool product, like an automated drone, for rotating the pebbles in your rock garden. I suppose someone is probably frustrated about rock garden pebble rotation, but in this silly example, it seems more like a solution in search of a real problem. ## Finding problems, comparing problems We're not looking for solutions (yet), and we're hoping to solve problems for an identified user group. Finding problems that are worth solving is challenging. What is a good problem? Do enough people have this problem? The most famous version of this question that I hear (and which I don't like) is: "Is it a vitamin or a painkiller?" (Implying that vitamins are only nice to have.) I argue that the severity of the problem might factor into usage frequency, value provided, and pricing, but it doesn't factor into whether or not a problem is real (or not). ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. For example, many of the most popular products don't solve a real pain point (at least not in my opinion). Let's take Spotify. It is a hugely successful product and company that solves the problem of users being unable to access virtually any song they want to at any time. Access to a vast music catalog is a valid problem. It isn't life-threatening. There was music before Spotify (and there will be music after). One might argue that this problem and solution is a vitamin, not a painkiller, but it might be a real pain for some people. Either way, it is a real problem; you can build a product to solve it. The question related to this is: Can you be a product manager at Spotify if you don't care about music? Perhaps Spotify wouldn't want you to be, but if you were good at being a product manager, then yes, you absolutely could. In technology companies, especially startups, all hiring managers, especially founders/CEOs, are seeking people for whom the problem is personal. This is a shortcut to solving the first issue noted above more than anything else. I agree that product managers who are solving problems where they are users have an easier time and, perhaps, can come up with new problem statements more rapidly. However, it is absolutely not a requirement, and hiring managers may be missing some great opportunities by making this a requirement. In one last example, when I worked at Green Dot, we made reloadable prepaid debit cards for the unbanked. Not surprisingly, most of the company, including the product team, was banked. We had to work harder to understand our users' motivations and empathize with their problems. While understanding our users is an achievable goal, finding unbanked technical product managers was unlikely. If you want to build a great product, you need to spend time with your users, understand their real problems, and focus on articulating that clearly and in a prioritized way. Only then can you focus on how to solve the problem at hand. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Building Great Product and Tech Relationships - ProductFTW #24 URL: https://www.productftw.com/productftw-building-great-product-and-tech-relationships/ Last updated: 2026-05-10T23:40:06.000Z *Note: Today, we are featuring a guest post from our friend,* [*Todd Zino*](https://www.linkedin.com/in/toddzino/?ref=productftw.com)*. Todd has 20 years of experience leading product, data, engineering, and design functions on both sides of the Atlantic, from seed-stage startups to profitable companies.* Building a great product requires great relationships across an organization's various builders. This is particularly critical when it comes to the relationship between product and tech roles. Most of us have had experience with conflict in these areas, both the healthy and unhealthy kind! As a lifelong technologist who loves building products real customers will actually use, I am unfortunately old enough to remember what it was like to be a manic coder in the days before Product Management became a key part of team structures, let alone everyday concepts like cloud automation, agile process, continuous delivery, and other improvements we now take for granted. All of these things have vastly improved the developer experience, but they also require an evolving mindset to ensure that the right bits are being built at the right time with the right resources (people and otherwise). ## **What, Why, How, & When are a Continuum, Not a Sequence** The biggest collaborative challenges often come from a mistaken belief that there is a clear separation of autonomous responsibilities to define ‘what’ and ‘why’ (product manager) and then sequentially figure out the ‘how’ and ‘when’ (engineering team). This is immensely disempowering not only to developers but also to product managers. That “double diamond of design” visual you may have seen only further leads to this misinterpretation – if you merely read it from left to right and assume product wholly owns the first diamond and tech the second: ![Image of a double diamond with "Discover", "Define", "Develop", and "Deliver".](https://lh7-us.googleusercontent.com/docsz/AD_4nXdPs3vQ2cUHeil5PVqFNygafWpd4IUaqiMGIg36qejhISHKEnaC5k8cAOC8acR4u-sVMNTjFyp9G8fV-pEKFJ0yHfWMAj_ip4_xhC7mUBxFF1ErbNiUpOqmSIpNJ1Cx_oPTR4dPCIMaRM8KUSnpTqOBKW64?key=hD3HGr-UkoUzcyJTDa7IEg) In reality, there is a cyclic and codependent relationship across these concepts that require shared ownership and reconciling the “top down” and “bottom up” views of building products. In my experience, I’ve found the biggest wins when there is a shared understanding of current capabilities vs. desired capabilities for prioritizing outcomes now, next, and later. This requires tech and product leaders on a team putting in the time outside of ceremonies or standing 1:1s to really challenge each other on this alignment. ## **Capabilities and Gears** In the ideal agile world, speed to outcomes and learnings are the “north star”. This assumes that any outcome can be engineered with a few tweaks to an existing resource set (people, codebase, vendor tools) under the remit of the team. Reality is rarely this simple, and often leads to either ‘feature factory’ churn or mounting ‘tech debt’ to achieve the smallest iteration possible that delivers value within one ‘sprint’. A better approach to product-tech collaboration involves seeing the product lifecycle as a continuous gearset of capabilities and outcomes that can operate as concurrent swimlanes: ![Image of a large and small gear working together.](https://lh7-us.googleusercontent.com/docsz/AD_4nXeASLy6TEo-lZtGXhvgrrGHPBzvIt79kxgo5RyFdVTLMKYy7BgkermookR3XQI3KOkXSJJoVCGjyEy3ujdyYsiDVLcqAyJXf5hRR3Ltdgr-xchEtOPpLGijEU9_vxHdp04cCPOtmS__5_33IDqHCKfMmjJQ?key=hD3HGr-UkoUzcyJTDa7IEg) In this model, the ‘small gear’ is the continuously tested, delivered, and measured work that can be done with existing capabilities. The product manager and tech lead on a team are ultimately accountable for keeping this wheel moving fast, but tactical delivery and measurement work can often be delegated to other roles (a specific engineer, an analyst, or a designer) to free up the leads to consider the big gear. So what is the big gear? This is the team’s capabilities that allow for rapid delivery towards outcomes and better experience or proposition tests. Prioritizing these capabilities requires aligning the “top-down” view of ultimate strategic outcomes (be they OKRs, the mission of the team, KPIs of a business unit) with the “bottom-up” view of effort required, build-vs-buy solutions, external team dependencies, data models, etc. A product and tech lead need to constantly harmonize to challenge, propose, and prioritize this view together rather than throwing them back and forth over an imaginary wall between fiefdoms. In my experience, this has been brought to life with collaborative visuals of the current and target ‘product architecture’ (i.e. more focused on data flow and interfaces than the specific microservices and cloud components in a traditional tech architecture), or a [RICE](https://www.productteacher.com/articles/product-manager-guide-to-rice-prioritization?ref=productftw.com) model of initiatives that really probes on effort vs reward at different timescales. In summary, any team at any level – from cross-functional agile teams to the C-suite of a company doing quarterly planning – should think of the capability changes they want to bet on (big gear) and the iterative outcomes they want to accelerate by continuous delivery, testing, and learning (small gear). All roles across a team (particularly its leadership) have a shared responsibility across these conceptual gears. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## **Building Good Product-Tech Relationships at Every Level of the Organization** So, how does this shared responsibility manifest itself at leadership levels above and across individual delivery teams? In a well-designed organization (ideally one that respects [Conway’s Law](https://en.wikipedia.org/wiki/Conway%27s%5Flaw?ref=productftw.com) :) ) with enough distinct product delivery teams to warrant layers of functional leadership (e.g., Head of Design, VP of Engineering, Director of Product) below an executive team, there will likely be ‘vertical’ ways of dividing the remit of teams across business areas (e.g., marketing or operations support) or customer needs (e.g., onboarding, retention, or app experience). These product and tech leaders heading up a functional set of teams need to be aligned on the distribution of resources across those teams and the performance of the people within those teams, ideally using the same capabilities vs outcomes framework I outlined above. The gaps in understanding I’ve most consistently observed are: 1. Product leadership being unaware or unaccountable for ‘back office’ or ‘platform’ engineering teams that have no resident PM (this is a whole topic for another day!) 2. Tech leadership being unaware of the fundamentals and research that underpins financial growth and market development. Improving this calibration requires not only agreement on the strategic goals of their area, but on the gory details of quantifiable effort required vs. the resources currently allocated and the “return on investment” these bigger initiatives will ultimately yield for the business. One area that consistently bites even well-intentioned organisations is the selection and integration of vendor tools that enable non-technical teams to build and iterate on customer journeys (e.g. CMS and CRM software tools). This is a great place for product and tech leadership to achieve joint understanding with their senior management counterparts in marketing, operations, finance, etc. and continuously leverage the right tools for the right outcomes in their roadmap. Closing these gaps requires putting in the work to achieve shared understanding and sense of urgency, whether this comes in the form of workshops, strategy days, or reallocating the right balance of tech and product roles to tackle these ‘known unknowns’. **Advice for aspirational product-minded CTOs or CPTOs** Over the past decade, more organizations have elected to split or combine the executive roles for product, technology, and even data or design on the C-Suite. This has given rise to the role of Chief Product & Technology Officer, which I’ve had the pleasure of serving in at a few scale-ups in the United Kingdom. There is no right or wrong answer as to whether organizations need one or more roles covering these functional areas, nor does it wholly depend on the industry or stage of the company. It’s correlated a lot more to the vision and skillset of the CEO, and the ideal spread of skillsets and decision-makers at the C level. The CPTO role often works best when there is a clearly shared or mandated vision coming from the very top, and therefore tightly coupled strategy and delivery across the most expensive resource in most digital-first companies (engineers, designers, PMs, data practitioners) For aspiring CPTOs, my biggest learnings are to: 1. Delegate and upskill a balanced senior management team reporting to you 2. Foster great relationships and ideal team structures at each level 3. Treat your data, platform, and infrastructure as a product just as important as customer-facing outputs, and apply the same PM and customer mindsets wherever possible 4. Ensure you balance the strategic needs of your executive peers and ruthlessly focus on ROI across the distributed investment of resources you will be accountable for And for CTOs who want to really succeed strategically in their role: never adopt or accept a passive role that is restricted to managing delivery costs, speed, or uptime. Whilst all C-Suite practitioners should take a service-oriented customer-first approach not only with the company’s end users but their executive colleagues, it is equally important to be highly engaged in the ‘what’ and ‘why’ and question ‘wants’ vs ‘needs’ when it comes to betting on achieving the company’s vision. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Opinionated Product - ProductFTW #23 URL: https://www.productftw.com/productftw-23-opinionated-product/ Last updated: 2026-05-10T23:40:05.000Z In this week's ProductFTW, I want to discuss opinionated product management and the challenges of balancing customer demands with your vision in B2B software development. Let's start with the basics. An opinionated product has a strong vision of the problems it intends to solve and how you will solve them. It often uses specific design and workflow choices to guide users toward a particular way of using it. Inherently, this means you won't be able to accommodate every use case or request. Now, let's get into it: ![Image of a scale balancing "Customer" and "Vision"](https://www.productftw.com/content/images/2024/06/customer-vs-vision.webp) The great dilemma Two competing forces often arise when planning a product roadmap: external requests and your product vision. Balancing these can be significantly challenging. To illustrate this, let's use an example: a sprinkler system for landscaping companies. Consider companies like Rachio or Orbit. In this example, we'll primarily focus on the software features and ignore the hardware. Suppose your family owns a landscape management company, and you've experienced the complex task of managing multiple sprinkler heads and zones across numerous properties. You believe there is a compelling problem to be solved, and you know exactly how you'd like to solve it. Using your family business as a reference customer, you identify the key features needed: - Grouping products - Grouping lawns - Setting and adjusting timers - Identifying zones Additionally, there are aspects like user management, determining who can log in and perform specific tasks, and reporting on water usage and sprinkler activity. While there are many features to consider, we'll focus on building a Minimum Viable Product (MVP), which we will cover in another ProductFTW. With your family (reference customer) providing feedback, you design and develop your features and set priorities. Everything seems to be on track. As you refine your MVP and prepare to go to market, you encounter two types of potential customers: - massive companies with 10,000 lawns requesting IoT integrations and customizations - smaller companies requesting integrations with popular account software. Both present specific feature requests that stray from your original use cases, forcing you to decide how to solve and prioritize them to secure these customers. You now face a dilemma: should you stick to your vision or cater to specific customer demands? You need to consider the revenue and growth potential of each request and ultimately make a decision: 1. Chase revenue by fulfilling the big customer's requests, even if they are highly specific and unique. This might lead to building a highly customized system, requiring feature flags or other configurations to hide certain features from other users. 2. Prioritize the smaller customers' requests, aligning them with your roadmap, albeit ahead of schedule. This will still generate some revenue. 3. Stay true to your vision and say no. Validating your vision and learning from customers as you solve their problems is essential. However, many businesses struggle to maintain focus and often lose sight of their vision in favor of chasing revenue. ![Image of a man with his hand raise with the caption "Product Management: Where your job is to say 'no' 99% of the time"](https://www.productftw.com/content/images/2024/06/say-no-meme.webp) Yes, there is a meme site specifically for product managers. Companies that cater to every customer request struggle with technical debt and maintainability over the long term because their systems become overly complicated. This creates problems for customers and team members who don’t understand features and how they work because there’s no single way to do things; there are multiple ways. An example that comes to mind is my early consulting days when I helped a major utility with five different ways to handle accounts payable within the same division. Accounts payable is not that hard. You get a bill, approve it, pay it, and reconcile it, but they didn't know the best practice and didn't have an opinion. Resulting in an overly complex system. Saying no to certain revenue opportunities can be tough but necessary for long-term success. It requires that you accept that some customers will not like your opinion. Over time, you may find that your solution meets their needs in ways they hadn't considered or that your approach is actually better. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. So, for me, an opinionated product is really about being the expert, having a clear vision of your roadmap, and trying to take as few detours as possible. This doesn't mean you never adjust your roadmap. Don't get me wrong here. Shifts should occur when there's a preponderance of evidence, plurality, or even a majority of users say, "Hey, we need to see this differently." Otherwise, what you're doing really is just catering to the whims of different users and it's a price you're going to pay for down the road. Ultimately, you cannot be everything to everyone. Trying to be everything to everyone means you are nothing unique to anybody. So, I always encourage companies to have a clear opinion and focus on that. Of course, this is easier said than done. We know it's a challenge, but we wish you the best. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### PM Job Hunting: A Firsthand Account - ProductFTW #22 URL: https://www.productftw.com/navigating-job-hunting-as-a-product-manager-in-2024-a-firsthand-account/ Last updated: 2026-05-22T02:07:33.000Z ![AI generated image of a man worn down and tired from job interviewing](https://www.productftw.com/content/images/2024/06/DALL-E-2024-06-12-11.34.16---A-realistic-animated-art-style-image-of-a-tired-looking-man-sitting-in-front-of-a-computer-at-home-with-his-resume-displayed-on-the-screen-without-a-p.webp) Your face after explaining your 'greatest weakness' for the 17th time In today's competitive job market, finding a new role can be incredibly challenging, with many facing the added pressure of widespread layoffs and an influx of candidates vying for the same positions. Recently, I had the opportunity to interview a product manager who wished to remain anonymous. They shared their journey over the past year, offering a glimpse into the harsh realities and complex, multi-step job-hunting processes in today's market. Here’s their detailed account: --- ### **Application Process** The first step in any job hunt is the application process, and our product manager was no stranger to this. > I applied for roughly 160 roles, mostly found via LinkedIn. However, I almost always completed the application directly on the company's website. I rarely used the 'easy apply' feature on LinkedIn. It’s a staggering number, revealing the competitive nature of the market. But what about the responses? > Out of those applications, 17 resulted in at least an HR or recruiter screener. That's just over a 10% response rate, highlighting how tough it can be to get a foot in the door. --- ### **The Interview** Once they secured an initial response, the interview process began. However, no two processes were the same. > The only thing that was typical was the initial few interviews. After submitting the application and being contacted by a recruiter, I would have an initial or screener call with the recruiter or HR rep. We would briefly discuss the role, my experience, and compensation. Provided compensation expectations were aligned, I moved to the next round, which was always meeting with the hiring manager. After those two interviews, there was no typical process across the companies I interviewed with. The variety didn’t stop there. > Yes, there were massive differences. Some companies had as few as three meetings before completing the process, while others had between five and eight rounds of interviews, sometimes including presentations with a group. I also interviewed with two companies where I met with 10+ people before they made a decision. In hindsight, despite the effort, these processes helped me realize which companies were not a good fit. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. --- ### **Strategies** With such a daunting process, what strategies worked? > The most effective strategy was getting a personal introduction to someone in the company. Former colleagues' recommendations and introductions to high-level people typically resulted in a complete interview process. Other strategies included sending a short LinkedIn intro message to the job poster, keeping in touch with HR/recruiting contacts from prior interviews (which helped me secure my newest position), and seeking referrals from friends or former colleagues. Despite the challenges, there were enjoyable aspects, too. > I enjoyed digging deeper into the company after an initial interview request. Reading about people's success posts on LinkedIn and seeing how companies celebrated their people was most enjoyable. While most websites were unremarkable, the level of detail in developer or API documentation was always interesting. I usually found a few interview questions after reviewing the public documentation, which varied between companies. --- ### **Staying Motivated** Job hunting can be exhausting. How did they stay motivated? > Having a job during my search allowed me to focus on something else while waiting for various processes to continue or conclude. I feel for those part of layoffs who needed to focus 100% of their energy on the job search. I also had friends and former colleagues to talk to throughout my search, which often turned into vent sessions and provided feedback on presentations and interview techniques. Additionally, I maintained a bi-weekly therapy session, which helped with coping techniques and personal perspectives. --- ### **Challenges and Learning Moments** The road wasn’t smooth. There were definite challenges. > The most challenging part was not getting any usable feedback after an unsuccessful interview process. I always asked for feedback but rarely received anything useful. After spending significant time and effort on an interview process, constructive feedback would have been helpful for future interviews. So, what tools did they use to stay organized? > Since a resume is crucial for getting noticed by recruiters, I rewrote mine about a dozen times and used AI tools like Rezi ([https://app.rezi.ai/](https://app.rezi.ai/?ref=productftw.com)) for formatting and content review. I also used AI chatbots to generate cover letters, though I can't say if it directly resulted in interviews. Keeping detailed notes for each interview, including information about the interviewer and relevant job specifics, was also helpful. --- ### **Advice** The atmosphere of job hunting can be a rollercoaster. > In a word: grim. The competition was fierce, and finding an acceptable job was extremely difficult. LinkedIn, while useful for finding jobs, often added to the stress with its high application numbers and influencer advice. Occasionally, I would browse Reddit's /r/recruitinghell to see others' experiences, which was both comforting and disheartening to see how wide spread and common the struggle was across industries. Do they have any tips for others? > Experiment to see what works for you. Tools like Rezi and Chat-GPT can help improve your resume and cover letters. Networking and seeking referrals are also critical. Reading industry blogs can keep your knowledge up-to-date and provide useful tips. Lastly, taking breaks and incorporating some exercise into your routine can help maintain your mental well-being. --- ### **Final Thoughts** As we wrapped up, they had a few more words of wisdom. > Consider using professional services like resume writing, career coaching, and placement services if needed. By the time I landed my new job, I was burnt out and ready to take a break. Sometimes, taking a break is worthwhile, even if it means focusing on an existing job for a while before diving back into the search. --- Searching for a job in today's market can often feel like an endless, uphill battle. The fierce competition and varied processes can make the journey daunting and disheartening at times. However, it's important to remember that each step brings you closer to your goal, no matter how small. Stay resilient, keep experimenting with different strategies, and lean on your support network for guidance and encouragement. Don't lose hope. The right opportunity is out there, and with persistence and adaptability, you'll find your fit. Keep pushing forward, take care of your mental well-being, and believe in your potential to succeed. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Tips for Terrific Tickets - ProductFTW #21 URL: https://www.productftw.com/productftw-21-tips-for-terrific-tickets/ Last updated: 2026-05-22T02:26:23.000Z In [*ProductFTW #15*](https://www.productftw.com/productftw-15-user-stories/), we discussed constructing quality user stories, and in [*ProductFTW #13*](https://www.productftw.com/mastering-the-art-of-requirements-prds-that-actually-work/)*,* we covered product requirements documents. Today, we’ll discuss how to write terrific tickets. I’ve been using this material to train my product teams for over a decade. ## Why Does Ticket Quality Matter? Many tickets are extremely unclear because the person (product manager) writing the ticket is focused more on speed than on quality. However, when your original ticket is clear, your issue (and the work required) will be understood and resolved much more quickly, with less back-and-forth communication required. By slowing down and taking your time to write the ticket initially, you will speed up overall delivery. ## Examples of Bad Tickets > I need the admin tool to take my uploads > Update the doc so that it’s not out of date > Make sure Bob can use the Admin from home > Fix bug user reported logging into iOS 17.1 ## Components of Good Tickets Every ticket, regardless of type (e.g., bug report, user story, compliance task), should contain the following, at a minimum: ![The image depicts interconnected circles with labels: "Title," "Description," "Impact," "Prioritization," and "Due Date," connected by a wavy line.](https://www.productftw.com/content/images/2024/06/Clear-Acceptance-Criteria-1.png) All good components look like tennis balls. ### Good Titles Good titles are brief but descriptive. When I first built this presentation at a company with \~12 product managers and \~100 technical staff, I reviewed hundreds of tickets and found that the best ticket titles had an average of **seven words**. Good titles include the impacted user, system, or process. ### Good Descriptions Writing a good description is easy, just remember those five “W”s you were taught learning how to write in elementary school: - **What:** What is the ask? What must be true for the request to be complete? Be descriptive! - **Who:** Who is the primary user of the request? Who is impacted? - **When:** When does the issue occur? What scenarios does the request apply to? Is there a timeline commitment or dependency? - **Where:** Where does the issue occur? What systems or applications are impacted? - **Why:** Why must we do this? What happens if we don’t? ### Impact It’s important to provide context to the team working on your ticket. You can do so by being clear about the positive impact of ticket completion (or the negative impact of the ticket remaining incomplete). For issues or bugs, try to answer questions such as: - How many clients/users are impacted? - Are the users blocked from performing their intended actions? - How meaningful is the action? - Is there a workaround? - Are there direct financial impacts? What if we did not solve this issue? - Is there any data loss? For new feature requests, the questions have a different tone: - How many clients/users benefit? - Does the request save time or money? How much? How do you know? - Is there a financial upside? How much? Over what period of time? - What happens if we don’t build this feature? ### Prioritization No surprise: Listing prioritization on the ticket is critical. *If you don’t prioritize the ticket, you’re asking someone else to do it, and they may not like it!* Use this table to select prioritization: ![Table describing common priority levels P0-P3](https://lh7-us.googleusercontent.com/TJomHbFQzpH4cirOjREoZ7K6zW_PuMnd49fmuqX45AeSObrHQWa1jCPIJZMYu1KU7tdEqM5JRnen0Bd8E9Gs530vxc9gmBEw3eGPLwU-pwIfmXmQpTJL3QFA00MspeCp23lvVeCA94kZqJ2JAXBc4d4) Save this for future reference. ### Due Dates There are two types of acceptable due dates to add to a ticket: 1. Specific delivery requirement. For example, a date when a feature or fix was promised to a customer or is required by compliance or legal need 2. Dependent dates. For example, when another ticket or task depends on the completion of this task. In many cases, developing the final date involves negotiating with the development team, but you have to start somewhere. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. ## Good Tickets So, what’s an example of a good ticket? **Title:** *Enable HEIC uploads of ID verification docs during KYC Processes* **Body:** *As a Tier 1 support agent logging into the administration interface, I need to be able to upload HEIC files of large sizes of driver’s license photos, because that is how users submit them from iPhones. Currently, the admin is only able to accept JPEG or PNG, meaning we have to ask users to resubmit, causing an additional delay and touch to the ticket an additional time.* *This is a P2 item; it affects 10% of users each day in the KYC queue.* *We have committed to the customer that we will resolve this within 30 days to improve our ticket response time and process.* **Impact**: *We can save an estimated 75 hours per week in support time.* ## Rewrites are inevitable Even when you write a good ticket, unforeseen questions will arise, requiring edits to improve clarity and ensure new information is captured. Good (most?) ticket tracking systems store versions so you can see these edits. ## Conclusion The quality of your tickets can significantly impact the efficiency and effectiveness of your product development process. Clear and well-structured tickets reduce misunderstandings and minimize the need for back-and-forth communications, ultimately speeding up the delivery of solutions. As you incorporate these practices, you will likely see a marked improvement in the speed and quality of your product's development cycle. Keep refining your approach, and encourage your team to do the same, ensuring everyone benefits from clearer, more effective tickets. ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### The Challenges of Context Shifts - ProductFTW #20 URL: https://www.productftw.com/productftw-20-the-challenges-of-context-shifts/ Last updated: 2026-05-10T23:40:01.000Z ProductFTW is about the skills and challenges of building software products. We can learn a lot from other types of work. A lesson from my mechanic inspired today's post about how PMs manage workloads and development cycles for their development teams. ![](https://www.productftw.com/content/images/2024/05/Empty-auto-mechanics-shop.png) A few years ago, my mechanic told me about his plan to buy the building next to his current shop. I asked if he would have trouble hiring more mechanics–he has previously told me that was a challenge. He surprised me by saying that although he was doubling his shop space, he was keeping his crew the same size. I asked him to explain. He told me that in the current shop, each mechanic has a single bay, including a lift for working on the car's underside. What often happens in their business of diagnosis and repair is that a car is brought into the bay, lifted up, diagnosed, and then work stops. There are two reasons work stops: 1. The customer needs to be called with an estimate and to approve the work 2. Parts need to be acquired, some of which can be delivered on the same day, but others may take longer As a result of the stop, the mechanic will bring the car down, including putting some things back together (e.g., putting a wheel back on), the car is moved to the yard, and a new car is brought into the bay. Later, when the customer approves of the repair, and all the repair parts are in, the mechanic can put the car up and finish the job (or hit a new block and wait all over again). By adding a second bay for each mechanic, the crew can work on two cars at once. Leaving a car up on the lift reduces effort in the swapping, and enables faster shifts to the second job, while the first job is in a wait mode. Brilliant (and maybe obvious to people who repair cars for a living). The entire concept had me thinking about the stops, starts, and context flows in software development. There are two types of context-shifting problems that I see in front of development teams: 1. Waiting for approval or feedback 2. Solution design challenges When PMs design a cycle, they are often focused on pure priority and do not consider what approval flows may exist mid-cycle (e.g., after a solution is designed, what the engineer is doing during testing/feedback/approval). Software development is a creative pursuit, and sometimes engineers hit a block when thinking about how to solve something. Giving any engineer a couple of different tasks to work on can enable them to set aside a problem for a day until a solution comes to mind while not losing productivity. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. In poorly run cycles, there are a lot of mid-cycle disruptions, such as shifts in priorities, urgent customer fixes, etc. Each of these creates a context shift, akin to pulling a car off the lift, putting a new one in there for different work, returning to the other car later. That can disrupt the coding flow leading to real challenges in productivity. Overall, focus is beneficial to productivity. Once you are stuck waiting for approvals, feedback, or inspiration, switching contexts can also be positive when you have something new to work on to fill time or spark creativity. How can software development teams handle this? There are a number of solutions: 1. Two Bays, or big rock/small rock: Each developer gets a meaty project per cycle, plus some small ones, allowing them to manage these shifts as they get stuck or simply desire new work 2. Rotating Kanban Duty: Most developers on the team are focused on core development, with one developer taking duty each cycle for the interrupt-heavy urgent fixes run on a separate Kanban board. The developer on duty rotates throughout the team 3. Concentrated Cycles: Thoughtfully ensure all tickets in a cycle have a similar theme so that interruptions and shifts are not very large. In our car analogy, this would mean giving the same mechanic two Honda brake projects at a time instead of one Honda brake project and one diesel engine rebuild. What works for you and your team to manage the interruptions and context shifts of modern software development? ## **About ProductFTW** [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Project Management (Not Product Management) - ProductFTW #19 URL: https://www.productftw.com/productftw-19-project-management-not-product-management/ Last updated: 2026-05-22T02:07:24.000Z *Note: Today, we bring you a guest post from our friend,* [*Julia Baker*](https://www.linkedin.com/in/julia-baker-187496/?ref=productftw.com)*. She began her career as a Project Manager at First Data. She progressed through roles such as Technical Program Manager at Yahoo!, Senior Program Manager at Amazon, and Senior Director of TPMO at ServiceTitan. Most recently, she served as VP of PMO at System1.* ![Illustration depiciting elements of proejct management](https://www.productftw.com/content/images/2024/05/DALL-E-May-22-Illustration.webp) **The Value of Project Management in Software Development Teams** As a professional project manager who intentionally chose this career path, I have witnessed my profession undergo significant challenges over the last few decades, especially within software development. When product management emerged in the 1980s, it became more economical for some companies to assign all non-technical tasks to this single role. Then, in the early 2000s, with the emergence of the Agile Scrum Master, the broader job of Project Manager (which is framework agnostic) was replaced in many companies with the more narrow Scrum Master role. Jeff Sutherland, one of the founders of Scrum, famously exclaimed in his book ***SCRUM: The Art of Doing Twice the Work in Half the Time*,** “I went to the CEO and told him we were scrapping the Gantt chart. He was shocked and demanded to know why. ‘How many Gantt charts have you seen in your career?’ I asked. ‘Hundreds,’ he replied. ‘How many of them were right?’ He paused. ‘None.’”1 The Project Manager became the boogeyman, a relic of the past associated with waterfall projects and (the horror) Gantt charts. This trend continued through the years, and the title Project Manager in Software Development organizations became less common, replacing it with Program Manager, TPM, Scrum Master, Delivery Manager, Release Manager, and a few others. While the title may change, the job remains the same. Despite this perception, I contend that the profession of project management remains incredibly valuable and has evolved to be crucial in the era of product-led growth. It's important to note that the purpose of a Gantt chart is not to be infallible but to visualize the known tasks on a timeline while accommodating changes. Today, these Gantt charts have become even more powerful with [generative AI tools](https://www.cadencepro.ai/?ref=productftw.com) that can simulate project scenarios. **What is Project Management?** A 1976 article in [Project Management Quarterly ](https://www.pmi.org/learning/library/project-management-services-art-science-5657?ref=productftw.com)defined project management as “the art of coordinating resources and directing unidisciplinary groups so that the components of work performed by each group accumulate into a multidisciplinary team effort which achieves the desired objectives (or contracted scope of work) on time and within budget.”2 In business schools, Project Management is taught within the scope of Operations Management, encompassing not only the management of the projects but also the improvement of operational processes within an organization. In modern software development organizations, project managers do more than run meetings, resolve blockers, and push projects forward. They also coordinate releases, facilitate brainstorming and planning sessions, and continuously refine workflows to enhance business impact, team happiness, quality, and time to market. Most project managers are hands-on in creating dashboards, project boards and documents to improve visibility on progress. They run the Agile rituals and/or coach the team on best practices. They keep up with new literature in the industry and collaborate with peers to learn new techniques and tools. **The Diminishing of the Project Management Function** Recently, [the trend in layoffs](https://www.businessinsider.com/meta-layoffs-tpm-roles-instagram-job-cuts?ref=productftw.com) has hit project management teams very hard. The reasoning seems simple: anyone can run meetings, track projects, and communicate progress—so why dedicate a role to it? The emergence of AI project management tools that create meeting notes and plans has given the illusion that the job can easily be spread out among Product and Engineering managers. While this might hold in some organizations with fewer touchpoints, in most, managing all the project dependencies and team members, ensuring everyone is aligned and delivering their parts, is a full-time job. **Why Dedicated Project Managers are Essential for Product-Led Growth** Project Management is an interrupt-heavy job. Product Managers and Engineering Managers need long stretches of uninterrupted time to think, create, and collaborate. Taking on project management responsibilities reduces their time for strategic thinking and running experiments to inform the next phase of product development. Without a project manager, managing delivery becomes the priority job, with commitments already made and developers already coding. Teams lose a neutral third party whose job is to resolve conflicts between team members, shine the light on key problems, and help ensure everyone is on the same page on what needs to be done. This shift takes the organization further from a [Product Led Growth](https://openviewpartners.com/product-led-growth/?ref=productftw.com) strategy, which is key to improved customer experience, better revenue per employee, lower customer acquisition costs, and a higher valuation. If you care about achieving these outcomes, consider having and empowering skilled Project Managers. This approach allows each role to focus on its strengths, ensuring that all phases of product development are effectively handled. --- 1 Sutherland, Jeff. **Scrum: The Art of Doing Twice the Work in Half the Time** First Edition., Crown Business, 2014. 2 Caspe, M. S. (1976). An overview of project management and project management services. *Project Management Quarterly, 7*(4), 30–39. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Should Product Managers be Technical? - ProductFTW #18 URL: https://www.productftw.com/productftw-18-should-product-managers-be-technical/ Last updated: 2026-10-14T01:25:32.000Z ![](https://www.productftw.com/content/images/2024/05/techpm.jpeg) Here’s a [$200,000](http://web.archive.org/web/20240810204024/https://www.levels.fyi/t/product-manager/focus/product?countryId=254&country=254) question for you: should a Product Manager be technical? Short answer: Yes. Long Answer: Absolutely, yes.\* As a former engineer with a Computer Science degree, I’m biased. But I can confidently say that my technical expertise has been a game-changer in my product management career. It's provided a solid foundation for growth and has allowed me to bridge the gap between business and technical aspects more effectively than many of my less technical peers. However, I also acknowledge that technical skills, while incredibly valuable, are not the only factor that determines success. In this post, I'll dive deeper into why technical skills matter, explore the exceptions to the rule, and share insights on how you can thrive as a PM, regardless of your background. # Why Technical Expertise Matters for PMs Now, when I say “technical,” I’m not necessarily suggesting that you need to sub in when one of your engineers takes a vacation. 📣 In the world of SaaS product management, being technical means understanding how web applications work, knowing the key components that power your product, and effectively communicating with your development team. Your goal as a PM isn’t to write code or be a solutions architect. It’s about having a solid grasp of how your applications work under the hood and the fundamental concepts that underlie them. This understanding helps you guide your team to the best solutions for your users' needs. Knowing your application’s stack—including the frontend (HTML, JavaScript, and CSS) and backend (APIs, databases, etc.)—allows you to communicate effectively with your development team. You can discuss technical trade-offs, understand constraints, and make informed decisions that align with your product vision. Without this knowledge, you risk misunderstandings, delays, and a product that falls short of its potential. Being well-versed in the technical aspects of your product also means you can better advocate for your team and users. You can push back on unrealistic timelines, fight for necessary resources, and ensure that technical debt doesn't hinder future development. But what if you're not naturally technical? Does this mean you're doomed to fail as a PM? Not necessarily. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # \*The Caveat: Domain Expertise Can Compensate Now, before you start panicking about your lack of technical expertise, let me introduce a glimmer of hope: domain expertise. While technical skills are undeniably important for PMs, having deep knowledge and experience in your product's specific domain can be a powerful asset that helps balance the scales. One of my best buds, Miles, was a pharmacist with over a decade behind the counter and zero technical background. When he transitioned into a product manager role at a company that builds software for the pharmaceutical industry, his domain expertise became his secret weapon. Sure, he had to learn the basics of tech on the job, but his in-depth understanding of pharmacy law, the business of running a pharmacy, and the complexity of the medical field allowed him to make informed decisions, anticipate user needs, and communicate effectively with his engineering team. He knew the pain points, the regulations, and the nuances of his industry inside and out, giving him a unique perspective that his more technical colleagues lacked. Even without years of technical familiarity, Miles flourished as a PM and is now seen as one of the best PMs at his company, only a couple of years in. However, this isn't to say that domain expertise is a perfect substitute for technical knowledge. Ideally, you want to have a balance of both. But if you're coming from a non-technical background, your domain expertise can be the bridge that helps you succeed while you work on building up your technical chops. The key here is to lean into your strengths while acknowledging and addressing your weaknesses. Leverage your domain knowledge to make valuable contributions to your product, but also be proactive about learning the technical side of things. Collaborate with your dev team, ask questions, and seek out resources to help you grow your technical skills over time. # Bridging the Gap: Learning Technical Skills There’s no silver bullet to becoming a more technical PM. To be blunt, it requires a lot of time and effort, so embrace a growth mindset. Start by diving into educational resources. There are countless online courses, tutorials, and blogs to help you learn the basics of programming, web development, and other technical topics. You’ll find plenty of beginner-friendly content on YouTube, Udemy, and similar sites. Some of my favorites include: - [ByteByteGo](https://blog.bytebytego.com/?ref=productftw.com) \- technical newsletter with great diagrams and easy-to-understand explanations of the tech that powers the biggest and best companies. - [Web Dev Bootcamp](https://www.udemy.com/course/the-web-developer-bootcamp/?ref=productftw.com) \- A zero-to-hero style Udemy web development course that I have recommended to several friends and colleagues and that I’ve gone through much of myself. - [Academind](https://academind.com/?ref=productftw.com) \- A plethora of detailed courses on just about anything under the web dev umbrella by Maximilian Schwarzmüller. If you’re anything like me, you learn best by doing. Once you’ve taken a programming course or two (you followed along and built all the tutorial apps, right?), build a simple web page or start tinkering with a basic app. As you gain confidence, take on more complex projects that stretch your abilities, like building a basic API. Hands-on experience is invaluable for cementing your understanding and helping you apply your knowledge in real-world situations. ❓ Could AI build a lot of this? Yes of course, but that won’t teach you anything. Learn the basics so you can use AI to its full potential. Another powerful strategy is to learn from the experts around you. Collaborate closely with your development team; don't be afraid to ask questions. Most developers are happy to share their knowledge and insights with curious PMs genuinely interested in learning. The best advice I could give here is to focus on understanding your app's architecture. Knowing how data flows through the application and what happens at each step is often more insightful than diving into the code. It helps you grasp the big picture—how different components interact, where potential bottlenecks might occur, and how various features are integrated. This architectural perspective lets you make more informed decisions and communicate effectively with your technical team. Remember, becoming technically proficient is a process, not an overnight transformation. It takes time, effort, and a willingness to step outside your comfort zone. But with each new skill you acquire, you'll become a more effective PM, better equipped to lead your team and create products that truly resonate with your users. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### For Whom Are You Building - ProductFTW #17 URL: https://www.productftw.com/productftw-17-for-whom-are-you-building/ Last updated: 2026-05-22T02:26:16.000Z I love upgrading my software. As someone building software professionally, I am eager to see what everyone else is working on. My eagerness to upgrade is often to my detriment, as early versions often contain bugs or some major change by the developer that isn’t to my liking. ![Man with a computer](https://www.productftw.com/content/images/2024/05/zoom-zoom.webp) That's exactly what I look like when this happens. Last week, I upgraded my Zoom app to their new major version, 6.0, and found myself thinking about both bad upgrades (this was one) and the choices PMs make for their business that can conflict with their users. To be fair to the PMs at Zoom, I have no data about Zoom user behavior and assume other people are like me. It’s 100% possible I am the anomaly. I spend **a lot** of my day on Zoom. As a consultant who advises CEOs on building complex fintech products and coaches leaders, I spend a lot of my day talking to clients. If I’m not doing that, I might be talking to potential platform providers who can help build solutions for my clients. Either way, there are a lot of back-to-back Zoom meetings. ![Screenshot of the Zoom 5.x Meetings tab](https://lh7-us.googleusercontent.com/eJ_uEsV_BnKfoK8Xo_t68Ur6sfiGG-ZbJDPCsWfKRzMUuPalQnz3Vw_plDUEkNLj2UuH3upadAWdo0WcfE17rUlkoE2tyh2CGwHhT4sO9iB2RRqfu_cwdtNgmdLAWv_Vi1A_Y0XmT_NaqQr9POjazq4) The old Zoom, look at this lovely meetings tab The old Zoom home screen would show you your current meeting with a Start or Join button and usually your next meeting. You could click “see today’s meetings” to see what was coming up. I found this feature useful because I often needed to jump to a meeting while another was in progress or wanted to start something a minute early, lest I forget. ![Screenshot of Zoom 6.0 home tab](https://lh7-us.googleusercontent.com/1KzlJXARQXGTaTbvrxNucHyFfNIKVjFDjOD-Q5WMYzBYp1MkQeFOuNl-tfz1p3pwUy9BEle6WRnkcsA4jaTR3hHINWb03fnDZNiiFcJB5dlqRANwv6FcKkpxyksIz6fnCrbxK1PwEu20OKqaZ6nIJWw) The new Zoom, clicking on this link should take me to that last view, but it no longer does. The new Zoom only shows me one current meeting. If I click to see more meetings, I am taken to a new calendar tab from my home screen. I already have a calendar app called Vimcal. If not, I might just load Google Calendar. While I have Zoom connected to Google to show me my meetings, it is not because I want a third calendar app. ![The Zoom Calendar tab](https://www.productftw.com/content/images/2024/05/Screenshot-2024-05-08-at-9.01.07-AM.png) Now, I get this calendar view. It's not great and takes a bunch of customization to get here. Here’s the conversation I imagine going on at Zoom: > Business Leader: “We should get more people to use our calendar. If they do, our app will be stickier. Also, we have that Calendly knock-off feature no one is using. People will use us as the one calendar/scheduling/meeting app to rule them all, and we’ll make loads of money on retention and upgrades.” > PM: “Okie-dokie, I can force people to look at that page.” In contrast, in most meetings I attend, the person on the other side jumps from meeting to meeting. I have discussed the #1 feature we actually want in Zoom, which is a button that doesn’t just say “End” or “Leave” a meeting but “End and Go to Next Meeting” so easily. I love Zoom. I am already sticky. I want to use my home screen. I want to jump from meeting to meeting. I also sometimes want to join a meeting 1, 2, or 3 minutes early or while I am already in another meeting. Either way, I don’t want to have to find the app after leaving a meeting and then figure out how to go to the calendar and click a bunch of times to get a new join button (I did reduce this by switching my calendar view settings to agenda from grid). ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. I’m singling out Zoom, but I have often felt as a user that product managers are allowing a decision that appears to be good for the business to override a decision that is good for the user. We should build user-centric solutions that align with our users' needs. When users love our product, they stick around, renew, and refer. The best products are user-focused, and the business follows (within reason; I mean, users also want everything to be free). I am sure that I have been guilty of this myself, as well. As a PM, we often have broader goals that the user isn’t aware of and try to drive people to those functions. You can’t force it; you must listen to your users! To pick on myself for a moment, I had a grand vision for my Wallaby app that people could use for card management: rewards maximization, fee avoidance, or cash flow optimization. We spent lots of cycles on making this obvious and educating users. What Wallaby users wanted was reward maximization, which was pure and simple. We should have gone to meet our users where they were, not tried to drag them where we wanted them to be. # Software Architecture Guide My brother is a highly-accomplished software architecture leader with a career that spans early-stage scientific software, two decades at Adobe, and his current leadership role at Autodesk. He published his first book this week: [*Effective Software Architecture: Building Better Software Faster*](https://www.amazon.com/Effective-Software-Architecture-Building-Better/dp/0138249326/ref=sr%5F1%5F1?crid=1EIRVQ147R8IR&dib=eyJ2IjoiMSJ9.OLCun9bHfPuREzROzUA1Yg.fBf70FPwND8h1zBYd1B8U2x2uLQbgi4cxpAAj3mlePE&dib%5Ftag=se&keywords=9780138249328&qid=1715049825&sprefix=9780138249328%2Caps%2C124&sr=8-1&ref=productftw.com)*.* I am biased, but I have my hands on a copy and recommend it to all engineering and product leaders! ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren't for giant tech companies. We know you don't have a full-time product designer on each team. We know your software probably hasn't been used by millions worldwide yet. We're here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### A Product Reading List - ProductFTW #16 URL: https://www.productftw.com/productftw-16-a-product-reading-list/ Last updated: 2026-05-10T23:39:56.000Z ![A set of books stacked side by side](https://www.productftw.com/content/images/2024/05/tom-hermans-9BoqXzEeQqM-unsplash.jpg) Photo by [Tom Hermans](https://unsplash.com/@tomhermans?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) on [Unsplash](https://unsplash.com/photos/book-lot-on-table-9BoqXzEeQqM?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) This week we are sharing some product management reads that we think are helpful wherever you are in your product management journey. ## Blogs [**The Product Manager**](https://theproductmanager.com/?ref=productftw.com) This blog provides a broad range of topics focusing on the fundamentals of product management, making it a great resource for continuous learning and staying updated on industry best practices. It offers practical advice and real-world examples to help navigate the challenges of building products in a fast-paced, resource-constrained environment. We like this blog because it provides actionable insights and relatable anecdotes that startup product managers can apply to their own unique situations. The blog's mix of humor and practicality makes it an engaging and valuable resource for PMs looking to build successful products and overcome the obstacles inherent in the startup world. --- [**Silicon Valley Product Group (SVPG) Blog**](https://svpg.com/articles/?ref=productftw.com) We are obviously fans of Marty Cagan, so we had to include the SVPG blog. It's a great resource for product managers seeking in-depth insights on product strategy, innovation, and leadership. The blog features thought-provoking articles that challenge conventional thinking and provide actionable advice for driving product success. We like the SVPG Blog because it offers a wealth of expertise and strategic guidance for startup product managers looking to create innovative, customer-centric products. Cagan's experience and insights provide a valuable framework for navigating the complexities of product management in a startup setting, making the blog an indispensable resource for PMs striving to build game-changing products. --- [**Sachin Rekhi's Blog**](https://www.sachinrekhi.com/?ref=productftw.com) Sachin Rekhi is a seasoned product management leader who has worked with companies like LinkedIn and Microsoft. His blog is a popular resource for product managers, covering a wide range of topics such as product strategy, user experience, and leadership. We like Sachin Rekhi's blog because it provides practical, actionable insights drawn from his extensive experience in the product management field. Rekhi's ability to break down complex concepts into easily digestible lessons makes his blog an invaluable resource for startup PMs looking to develop their skills and make a meaningful impact in their organizations. --- [**The Product Coalition**](https://productcoalition.com/?ref=productftw.com) The Product Coalition features articles from a diverse group of product managers, designers, and entrepreneurs. The blog covers a wide range of topics related to product management, offering insights, best practices, and lessons learned from professionals across the industry. We like The Product Coalition because it provides a range of perspectives and experiences from product managers working in various industries and company sizes. This diversity makes the blog a valuable resource for startup PMs looking to learn from the successes and challenges of their peers, and to stay informed about the latest trends and best practices in product management. --- [**Product Management Today**](https://productmanagementtoday.com/?ref=productftw.com) Product Management Today features articles from product managers, designers, and entrepreneurs. The publication covers a variety of topics related to product management, including product strategy, user research, and career advice. We like Product Management Today because it features articles from various product blogs and publications across the industry, so they are a good round-up of the product management conversations and insights that are being shared from blogs you might not be reading all the time. They also share a reading list at the end of every month of their top "must-reads" from that month. --- [**Product Talk**](https://www.producttalk.org/?ref=productftw.com) Product Talk focuses on the critical aspects of product discovery, user research, and continuous improvement. It provides practical, actionable advice for product managers looking to make data-driven decisions and create products that truly resonate with users. We like Product Talk because it addresses a crucial aspect of product management that is often overlooked in the fast-paced startup world. Torres' emphasis on user research and data-driven decision-making provides startup PMs with the tools and knowledge they need to create products that solve real problems and deliver value to customers, even with limited resources and tight deadlines. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Books ![Inspired: How to Create Tech Products Customers Will Love by Marty Cagan book cover](https://www.productftw.com/content/images/2024/05/inspired-cagan-2.png) [**Inspired: How to Create Tech Products Customers Will Love**](https://bookshop.org/p/books/inspired-how-to-create-tech-products-customers-love-marty-cagan/12571258?aid=94005&ean=9781119387503&listref=productftw-reading-list&ref=productftw.com) *By Marty Cagan* Marty Cagan provides a deep dive into the role of a product manager and the strategies used by top tech companies to create successful products. This book is valuable for its practical insights and real-world applications that can help product managers create products that not only meet but exceed customer expectations. We recommend this book because it both *inspires* and excites readers about the transformative power of effective product management, emphasizing that the customer should always be at the heart of any team's efforts. As mentioned previously, the strategies discussed are those employed by leading tech companies; however, it's important to note that they may not directly translate to startups or smaller organizations. ![Start With Why: How Great Leaders Inspire Everyone to Take Action by Simon Sinek book cover](https://www.productftw.com/content/images/2024/05/start-with-why.png) [**Start With Why: How Great Leaders Inspire Everyone to Take Action**](https://bookshop.org/p/books/start-with-why-how-great-leaders-inspire-everyone-to-take-action-simon-sinek/16673537?aid=94005&ean=9781591846444&listref=productftw-reading-list&ref=productftw.com) *by Simon Sinek* Simon Sinek explores how leaders can inspire cooperation, trust, and change within an organization. It's essential for product managers who need to motivate their teams and align stakeholders around a common vision. The first time I read this book early in my career, I was blown away by how simple yet crucial the concept of focusing on "the why" is. This book is a fantastic resource for understanding how centering on the reasons behind your actions can transform your entire organization and mindset. It also offers practical advice on how to determine your own "why." ![The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback by Dan Olsen book cover](https://www.productftw.com/content/images/2024/05/lean-product-playbook.png) [**The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback**](https://bookshop.org/p/books/the-lean-product-playbook-how-to-innovate-with-minimum-viable-products-and-rapid-customer-feedback-dan-olsen/16598257?aid=94005&ean=9781118960875&listref=productftw-reading-list&ref=productftw.com) *By Dan Olsen* This book offers a repeatable, easy-to-follow process for iterating on product ideas, validating them with real users, and achieving product-market fit. It's invaluable for product managers looking to build products efficiently and effectively. We like this book because it lays out a clear, actionable process. It provides practical tools for identifying the MVP and gathering customer feedback. While it's incredibly useful, keep in mind that there are many other methods available too. ![Predictably Irrational, Revised and Expanded Edition: The Hidden Forces that Shape Our Decisions by Dr. Dan Ariely book cover](https://www.productftw.com/content/images/2024/05/predictably-irrational.png) [**Predictably Irrational, Revised and Expanded Edition: The Hidden Forces that Shape Our Decisions**](https://bookshop.org/p/books/predictably-irrational-revised-and-expanded-edition-the-hidden-forces-that-shape-our-decisions-dan-ariely/8942152?aid=94005&ean=9780061353246&listref=productftw-reading-list&ref=productftw.com) *By Dr. Dan Ariely* Dr. Ariely's exploration of behavioral economics provides insights into why people make the decisions they do, which can help product managers design more engaging and compelling products. As a startup, understanding your users is the key to creating products that people will love. This book is a fascinating dive into the psychology of decision-making that will help you create products that resonate with your customers. ![Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri book cover](https://www.productftw.com/content/images/2024/05/escaping-the-build-trap.png) [**Escaping the Build Trap: How Effective Product Management Creates Real Value**](https://bookshop.org/p/books/escaping-the-build-trap-how-effective-product-management-creates-real-value-melissa-perri/8138080?aid=94005&ean=9781491973790&listref=productftw-reading-list&ref=productftw.com) *By Melissa Perri* Melissa Perri discusses how companies can avoid the "build trap," where they focus more on shipping features than on creating value. It's a crucial read for understanding how to align product development with business goals. In the fast-paced world of startups, it's easy to fall into the trap of constantly building features without thinking about the bigger picture. We think this book is a good wake-up call to focus on delivering real value to your customers if you might be losing sight of that goal in the heads-down efforts of building. ![Empowered: Ordinary People, Extraordinary Products by Marty Cagan and Chris Jones book cover](https://www.productftw.com/content/images/2024/05/empowered-cagan-jones.png) [**Empowered: Ordinary People, Extraordinary Products**](https://bookshop.org/p/books/empowered-ordinary-people-extraordinary-products-chris-jones/14688284?aid=94005&ean=9781119691297&listref=productftw-reading-list&ref=productftw.com) *By Marty Cagan and Chris Jones* This follow-up to "Inspired" focuses on how companies can enable their product teams to work at their full potential. It's particularly useful for understanding how to cultivate an environment where product teams can innovate and execute effectively. We appreciate this book because it offers valuable insights into structuring your product team for growth. Many smaller companies begin to expand their teams before defining clear operational strategies. This read is particularly useful for understanding how to establish an environment where product teams can thrive through innovation and effective execution. ![Principles of Product Management: How to Land a PM Job and Launch Your Product Career by Peter Yang book cover](https://www.productftw.com/content/images/2024/05/principles-of-product-management.png) [**Principles of Product Management: How to Land a PM Job and Launch Your Product Career** ](https://bookshop.org/p/books/principles-of-product-management-how-to-land-a-pm-job-and-launch-your-product-career-peter-yang/14190483?aid=94005&ean=9781654187231&listref=productftw-reading-list&ref=productftw.com) *By Peter Yang* This book is a comprehensive guide for aspiring product managers, covering everything from landing a product management job to excelling in the role. It's a great resource for beginners in the field. We like this book because it's a no-nonsense guide to breaking into product management in the fast-paced world of startups. Peter Yang's advice is practical, actionable, and based on real-world experience, making it a great resource for aspiring PMs. Whether you're a recent grad or a seasoned pro looking to pivot, this book can serve as a roadmap to landing a PM job and making an impact from day one. ![Build: An Unorthodox Guide to Making Things Worth Making by Tony Fadell book cover](https://www.productftw.com/content/images/2024/05/build-fadell-2.png) [**Build: An Unorthodox Guide to Making Things Worth Making**](https://bookshop.org/p/books/build-an-unorthodox-guide-to-making-things-worth-making-tony-fadell/18349996?aid=94005&ean=9780063046061&listref=productftw-reading-list&ref=productftw.com) *By Tony Fadell* "Build" is an insightful guide to product development and innovation by Tony Fadell, the creator of the iPod and the Nest thermostat. It offers a unique perspective on creating meaningful products that stand the test of time. We like this book because it provides invaluable lessons for startup founders and product managers who want to create products that truly resonate with users. Fadell's emphasis on focusing on the "why" behind a product, rather than just the "what," is particularly relevant in the fast-paced, often uncertain world of startups. His practical advice and real-world examples make "Build" a great resource for anyone looking to develop innovative, impactful products that solve real problems and create lasting value. ## **Happy Reading!** It's important to remember that the journey of a startup product manager is one of constant learning and growth. And the world of product management is always evolving, so there's always something new to learn. The books and blogs we've explored here are just a portion of the many great resources out there. We'd love to hear any recommendations you have about books and reading that we should add to our reading list! ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren't for giant tech companies. We know you don't have a full-time product designer on each team. We know your software probably hasn't been used by millions of people worldwide–yet. We're here to bridge the content gap from building your product and team to scaling it. ### User Stories - ProductFTW #15 URL: https://www.productftw.com/productftw-15-user-stories/ Last updated: 2026-05-22T02:26:22.000Z As product managers, our primary goal is to deliver high-quality products that meet and exceed user expectations. Essentially, we're aiming for what you might call *fanatical joy*. You’ve heard of “delight your user,” right? We accomplish this by providing accurate and thorough information to our development teams so they have a clear understanding of what will truly make the user happy. Among the most effective tools at our disposal for conveying these details is the user story. But what exactly is a user story? A user story is a short description of a product feature from the perspective of the person who desires the new capability, typically a user or customer of the system. It’s a formula that keeps your product's who, what, and why top of mind for everyone involved in its development: 📝 My favorite user story formula is: As a **user,* I want to **function* so that I can **benefit*. When I started as a product manager at CreditCards.com, we didn’t have a practice of writing user stories. More often than not, we found ourselves building solutions that were technically sophisticated but didn’t necessarily address the real needs of our users. Instead, we were inadvertently building for ourselves (the technology team), creating features that were more about showcasing our capabilities than solving actual problems. This led to overdeveloped solutions. One example that sticks out is how overly complex our website publishing was. Seriously, it took hours to publish a spelling correction. I still look back and shutter. We forgot who the end user was, and although it is normal for development to sit back and run a batch process overnight, our internal users didn’t expect that. A simple user story would have prevented this. **Example of a Good User Story:** ![](https://www.productftw.com/content/images/2024/04/good-user-story.png) “As product operations, I want an efficient publishing tool for our card listing pages that enables updates to be live within minutes so that card details are current and compliant with regulations.” This is a good example because it clearly states the user's problem and goal. **Example of a Bad User Story:** ![](https://www.productftw.com/content/images/2024/04/bad-user-story.png) "We need to publish our website." This is a bad example because it does not start with the user and focuses on the solution. ## Best Practices for Crafting User Stories - **INVEST in Your Stories:** Ensure each story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. This helps create stories that are manageable and actionable without being overly prescriptive. - **Be Specific and Realistic:** Vague stories lead to ambiguous implementations. Provide enough detail in your stories and acceptance criteria to guide development but leave room for technical creativity. - **Regularly Review and Revise:** User stories are not set in stone. They should evolve as new information is discovered and as project needs change. This iterative process helps align the project with user needs and business goals. ### Common Pitfalls to Avoid - **Writing Too Many Details:** Avoid turning user stories into fixed requirements. Over-detailing can stifle creativity and flexibility in finding the best technical solutions. - **Ignoring User Feedback:** User stories should adapt based on feedback from all stakeholders, including users, developers, and business representatives. Regular feedback loops are essential for refining stories. - **Confusing Tasks for Stories:** Ensure each story focuses on delivering value to the user rather than just completing tasks. Stories should always be outcome-oriented. ## Acceptance Criteria A user story is nothing without its acceptance criteria. Acceptance criteria specify the ‘conditions that must be met’ for the user story to be considered complete. They serve as a checklist that ensures every functionality introduced meets the user’s needs and the team’s quality standards. While the user story focuses on the 'what' and the 'why,' acceptance criteria define the 'how' to achieve it, making the story actionable for developers and testable for QA teams. ### **Best Practices for Crafting Acceptance Criteria** - **Specific and Clear:** Good acceptance criteria provide detailed and unambiguous details that must be met for the user story to be considered complete. They eliminate guesswork by providing exact parameters. Example: "Updates to card listings can be published live within one minute of submission by a content editor, and the system must confirm the successful publication with a timestamped notification to the editor." - **Testable:** It needs to be easily measurable. This clarity allows developers to create precise tests for each requirement, ensuring functionality meets the specified standards. Example: "The publishing system should allow content editors to preview changes in a sandbox environment, which accurately reflects the live site, before final publication." - **Achievable:** Given the project's scope, technology, and timeline, the criteria should be realistic. They should challenge the team to deliver high-quality work without setting them up for failure. - **Relevant:** Directly connects to the functionality described in the user story, focusing on solving the user's problem without including unrelated features. Example: "Content editors must be able to revert to the previous version of the content in case of any errors." ### Common Pitfalls to Avoid - **Vague and Ambiguous:** Vague criteria lead to subjective interpretations and inconsistent implementations, which can significantly deviate from the intended user requirements. Example: "The publishing tool should be user-friendly." (This is subjective and doesn’t specify what aspects make the tool user-friendly.) - **Non-testable:** Criteria that cannot be quantified or confirmed through testing are useless for developers or QA teams. Example: "The site should publish faster than before." (Without a specific target time, "faster" is too ambiguous and unmeasurable.) - **Irrelevant:** Criteria that do not support the specific goals of the user story lead to the development of unnecessary features, potentially increasing complexity and resource expenditures. Example: "The system should be compatible with all future content management systems." (While forward compatibility is important, this is too broad and irrelevant to the user's immediate needs.) - **Overly Prescriptive:** While clarity is crucial, overly detailed instructions on how tasks should be executed can limit the developers' ability to innovate or optimize the solution. Example: "Use specific CMS X version 2.34 for the publishing tool." (Unless a particular version is essential for compliance or integration, this type of specification may unnecessarily restrict technical solutions.) ## Putting it Together ![](https://www.productftw.com/content/images/2024/04/Clear-Acceptance-Criteria.png) Save this as a reminder! **User Story:** "As product operations, I want to be able to quickly publish our card listing pages, so that I can avoid posting misinformation or a compliance violation." **Acceptance Criteria:** 1. Timeliness of Publishing: 1. Changes submitted by the content editor must be live on the site within one minute of submission. 2. Notification of Publication: 1. Upon successful publication, the system must send a timestamped notification to the content editor confirming that the changes are live. 3. Preview Capability: 1. The system must provide a sandbox environment where content editors can preview their changes exactly as they would appear on the live site before finalizing the publication. 4. Error Handling and Reversion: 1. Content editors must be able to revert to the previous version of the content in case of any publishing errors. 5. Compliance Checks: 1. The system must automatically perform a compliance check on the content before it is published, flagging any potential compliance issues for review by the content editor. User stories and their corresponding acceptance criteria are the building blocks of successful product development. They ensure that every piece of functionality is directly tied to user needs, avoiding unnecessary features and misdirected efforts. Remember, a well-crafted user story and detailed acceptance criteria together create a clear path forward. As you continue to refine your approach to writing user stories and acceptance criteria, you'll find that these tools will help you better serve your users. Keep iterating and refining. The more aligned your stories and criteria are with your users' true needs, the more successful your product will be. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Presentation Skills - ProductFTW #14 URL: https://www.productftw.com/productftw-14-presentation-skills/ Last updated: 2026-05-10T23:39:53.000Z As a product manager, communicating effectively with your colleagues across the company is critical. Product managers own the vision, roadmap, and execution of their particular product, and, as discussed in [ProductFTW #11](https://www.productftw.com/productftw-11-leading-without-authority-as-a-product-manager/), you must lead without the authority of being the team’s direct HR manager, relying instead on the strength of your ideas and communication skills. ![Matthew Goldman & Todd Zino presenting at Finovate](https://www.productftw.com/content/images/2024/04/wallaby_finnovate.jpg) Me, presenting with my-cofounder Todd. So many Wallaby logos. One of the most effective ways to share critical information about a product or feature project is through presentations. However, when I mention presentations, I'm not referring solely to creating slide decks. Anytime you share information in a meeting (in-person, virtually, etc.), you're engaging in a form of presentation. I started my adult career as a consultant at Deloitte, where it often felt like all we did was make slides, so I have a particular interest in the topic. In this post, we will focus on a presentation using a series of slides. There will be instances where you might not have the opportunity to rely on your carefully designed slides and will need to communicate your message effectively without them, so also plan to be ready to adapt! ## What is your goal? The first question you should ask when working on a presentation is: “What is your goal?” What outcome do you want to achieve? Examples of goals are: - Disseminate information - Persuade someone to buy something (or approve a project) - Elucidate a debate With your goal in mind, you can start to craft the presentation outline. A great way to do this is to write a series of bullet points that will turn into the headlines of each page. By outlining the pages and flow of the presentation, you can ensure that your story has consistency and a logical flow. By creating an outline, you give yourself clear direction on what content each slide needs. You should view the slide body as a follow-up detail and aim for descriptive headlines that tell the story. For instance, a less effective headline might be “Market Opportunity,” whereas a more impactful one could be “Expanding services to larger businesses represents a $10MM opportunity.” Of course, there is a limit to the number of characters a headline can have, so some wordsmithing is usually in order. However, you can drive home a critical point in the largest font and at the top of the page by putting a complete concept into a headline. Then, back up that point with the detail in the slide. ## Formatting and layout issues detract from the context While most of us aren’t designers at ad agencies, we can design presentation slides that are of good quality and do not distract from the content we are trying to deliver. If your slides are poorly made, that is what people will focus on instead of the content. Slide presentations have a bad reputation because people tend to make poorly designed slides. ![A very bad slide](https://www.productftw.com/content/images/2024/04/wallaby_slide.jpg) This is a terrible slide. What was I thinking? I was at a conference last year with someone presenting something exciting to 300 people, and all I could think about was how hard it was to read. Don't let this be you! I recommend you develop your checklist to ensure you’re making it easy to read: 1. Don’t play with colors; make sure you have a strong contrast between the text and background 2. Don’t overload any one slide with too much content 3. Align different content boxes (left or center) 4. Make sure your bullets are clear 1. Alternate between the bullet “•” and the en-dash “-” as you go to further levels of bullets (or between numbers and letters for the ordered list) 2. If a bullet list only has one item, it’s not a list; don’t use a bullet 5. Check all of your spelling and grammar 6. Ask yourself for each element on the page: is this useful? ## Is a presentation in the correct format? It is critical to consider how to make your presentation. Amazon is famous for its use of long memos instead of slides. I don’t subscribe to the viewpoint that either format is better overall, but each format is valuable, depending on your goal. Using slides is excellent when you have mixed media. If you plan to have some text, images, charts, etc., slides are a great way to deliver content. On the other hand, if you find your presentation is all text, you should simply stop and write a Word document. The context of the delivery is also essential. A presentation is an excellent way to manage the flow if you have a live, interactive discussion. A narrative document is a better choice if you plan to simply email the presentation. One more thing, don’t use clip art! ![Bad Choices Behavior Clip Art](https://www.productftw.com/content/images/2024/04/bad-behavior-clip-art-whimsy_clips.webp) Clip art itself is a bad choice. Credit: Whimsy Clips ## Iterate, iterate, iterate A mix of slow and fast run-throughs can identify errors and flow problems. I recommend that you: - Read through your entire presentation out loud (to yourself or a trusted colleague) - Read with the slide titles only to ensure your story continues to make sense - Print it out and read it (or read it on an iPad) - View in slide sorter to get a view of the entire presentation at once ## Matthew’s rules for presentations *(in no particular order)* 1. Check for spelling or grammatical issues 2. Verify formatting is consistent across all slides 3. Use the same fonts and colors across all slides 4. Ensure spacing and bullets are consistent across all slides 5. Ensure alignment of content boxes 6. Do not use clip art (ever) 7. Do not use a font size under 12 points 8. Source & footnote everything 9. Do not read a slide during your presentation (ever) ## At the end: Always shorten and simplify Most slide presentations should be short: ten slides or less is ideal. If you find yourself with a long presentation, ask yourself: "What is most important?" Moving slides to an appendix enables you to be prepared without being too long on slides or time. An appendix allows you to jump forward, demonstrate you are prepared, and thought of the problem or issue beforehand without forcing everyone to sit through it if no one brings it up. Simplicity often makes a better slide. You should have the least possible content while making your point. Finally, be prepared if you are not allowed to use your slides! You may need to speak to them, and you should practice doing so. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Mastering the Art of Requirements: PRDs that Actually Work - ProductFTW #13 URL: https://www.productftw.com/mastering-the-art-of-requirements-prds-that-actually-work/ Last updated: 2026-10-14T01:25:31.000Z Ah, the PRD. The bane of every product manager's existence. We've all been there, staring at a blank screen, wondering how the hell we're supposed to dump all of our product knowledge into a few measly pages. And then, once we've poured our heart and soul into it, we watch in despair as it sits untouched in a dusty corner, never to be read again. Folks, let's be real—most PRDs are about as useful as a screen door on a submarine. They're long, boring, and often ignored by everyone except the poor sap who had to write them—**you**. But fear not, my friends, your PRDs don't have to suck. Today, we're going to explore the art of crafting PRDs that actually work. We'll dive into the essential components of a PRD, explore tips and tricks for making them concise and compelling, and uncover the secrets to getting your team to actually read and use them. Let's go! ![Meme with excited person finishing the PRD and sad person realizing no one will read it](https://www.productftw.com/content/images/2024/04/Finish-PRD--1-.png) Don't let this be you ## What’s a PRD? At its core, a Product Requirements Document, aka PRD, defines what you're building, who you’re building for, and how it addresses their needs. It's the blueprint from which your product team, designers, and engineers draw inspiration and direction. Critically, in a startup environment, it's less about rigid specifications and more about guiding principles that evolve as you build out your product. I like to treat PRDs as living documents until the product or feature has gone live because things will inevitably change as we start designing, building, and getting feedback from people. But we're getting ahead of ourselves: Let's start with the core components of a PRD before we talk about how to use them effectively. ## The Non-Negotiables: Essential Elements of a PRD You'll find infinite PRD templates online. Most are bad, some are good, but nearly all of them overcomplicate things. The best PRDs are short and to the point, especially at an early-stage company. Yes, documentation is important, but you don't need to spend all of your time trying to make it perfect–spend it talking to customers, building reports, analyzing data, coding…do literally anything except spending too much time writing the PRD. Assuming you know your product well, you should be able to create an entire PRD in **less than a day**, especially if you focus on just the essential elements of a PRD. The most straightforward PRD has only these sections: - **Problem to solve:** The "why" behind your product or feature, articulating the issues the feature or product the PRD aims to solve. This is critical because it ensures that everyone understands the purpose and value of what you're building. - **Objectives and Success Metrics:** How do you know you've solved the problem? Whether it's increasing sign-ups, reducing churn, or whatever metrics are most important to your business, you need to identify two or three clear goals with measurable outcomes that define what success looks like. These metrics will help you track progress and determine if your product is actually meeting its goals. - **User Persona:** Who are you building this for? This is just a sentence or two detailing your ideal user, ensuring that you're focused on real user needs. Understanding your target audience is crucial for creating a product that people will actually want to use. - **Requirements:** A high-level overview of the product's must-have features and functionalities. Requirements should be numbered and written in plain English. You should also include any applicable Acceptance Criteria. For example: ![text image with a user story](https://www.productftw.com/content/images/2024/04/Untitled_Artwork-6.png) Pro-tip: Never roll your own auth, unless, you know, you're Okta or something. With these four components, you should have more than enough information to get you and your team started toward building your sweet new feature. ## The Bells and Whistles: Optional PRD Components While the essential elements of a PRD will get you pretty far, complex, more mature products may require more thoughtfulness. These "supplemental" sections of a PRD will provide the specific details that bigger, cross-functional teams may require, particularly when dealing with a lot of features or products. This is not an exhaustive list, but some of the more common things to cover include: - **TLDR**: A snapshot of what the PRD contains, ensuring an immediate understanding of the product vision. This is especially useful for the people who won’t take the time to read the entire PRD (e.g., everyone). - Keep it simple: “We are solving this problem for this person, and it needs to do X, Y, and Z. We are measuring success by 1, 2, and 3.” - **User Stories**: Detail the explicit scenarios that describe how your User Personas will interact with your product, adding a human element to the requirements. (link to use story article). - These stories help your team empathize with the user and create a more user-centric product. - **UX**: Initial thoughts on user experience, typically a set of wireframes, acknowledging that the final design will evolve. This gives the team a starting point for the design process and ensures that everyone is on the same page about the general look and feel of the product. - Once the final mockups have been created, embed or link out to them in this section. - **Technical Considerations**: You probably touched on some technical elements in the Requirements section, but a deeper dive into the architectural and technical requirements is critical so that the engineering team knows not only what to build but *how* to build it. This is particularly important for complex products that may require significant engineering effort or deeper external integrations where outside collaboration with a partner or vendor is needed. - You might take a stab at this section, but typically, your engineering counterpart should be responsible for it. - **Scope**: The boundaries of what the product will and won't include are crucial for maintaining focus. Define at least the MVP and major follow-up releases as well. This helps prevent scope creep and ensures that everyone is clear on what will be delivered. - **Timeline**: A flexible schedule that anticipates adjustments as the project progresses. Call out the major milestones, like design completion, UAT, launch, etc. While timelines are likely to change, having a rough schedule helps keep the team accountable and aligned. - **Risks and Assumptions**: Potential hurdles and assumptions that could impact the product's development. Identifying these early on can help the team proactively mitigate risks and make informed decisions. - **Go-to-market**: Define how you will launch this feature and get the word out. This ensures that the product launch is coordinated with marketing efforts and that the team is prepared to support the product once it's live. I don't recommend including most of these things in your PRD at an early-stage startup unless you feel like it's needed to get buy-in or aid in comprehension. These items are still (mostly) important, but you'll figure most of them out on the fly. Overthinking it too much before collaborating with your team will just end in heartache. Odds are pretty good that your engineering team will tell you that one sweet feature will take six months to build, so you can throw everything related to your timeline, scope, UI, and GTM out the window. ❗ The only caveat to this is when you’re working with an external dev shop: The more details, the better since you typically don’t have a tight, collaborative relationship with them. ## I created the PRD: Now what? ![Underpants Gnoes image for write prd profit](https://www.productftw.com/content/images/2024/04/profit.jpeg) Easily the best characters on South Park ever were these gnomes With that PRD in hand, step one is done: score! Now, only…99 more steps to go. Once the PRD is written, the focus shifts from planning to action, iteration, and collaboration. We won't go deep into the full development process in this post, but the general sequence looks something like this: 1. After you've got a draft PRD ready to go, you need to share it with your team and key stakeholders, including design, engineering, sales, marketing, and customer support. This review process is crucial for alignment, identifying oversights, and getting different perspectives from others throughout the business. 1. When nobody gives you any feedback because they forgot to read it, shed those cats into a meeting to walk through it in real time. 2. Take that feedback and incorporate it into the PRD. Now, with general alignment, engineering will start to identify the technical specifications, and design can start creating the mock-ups. Add those things back into the PRD. 3. Development begins. 4. As features and major components are completed, you should test them against the requirements in the PRD. 5. If possible, test things out with some users before launch. This may result in some changes to the product based on their feedback- go back and update the PRD to reflect those changes. 6. Once everything meets requirements, has been thoroughly tested, and you've gotten some user feedback, you can pick a date to deploy your new feature. 7. Generate some buzz and launch that bad boy. This is an incredibly abridged version of what actually happens, but hopefully, you get the idea. Throughout this process, treat the PRD as the source of truth. If that truth changes, be sure to go back and update the PRD. It's critical that the PRD remains the single artifact that everyone refers to, and the only way that's going to happen is **you** keep it up to date. ## Other Tips Now that you have a solid understanding of what goes into a PRD and how it fits into the product development process, here are a few additional tips to keep in mind: ### Embrace the Journey Remember, your initial PRD doesn't need to be exhaustive. It's a living document meant to evolve. Start with a clear problem statement, objectives, user persona, and requirements. As your project unfolds, so will your understanding, allowing you to beef up the PRD with newfound insights and refined details. Don't be afraid to update the PRD as you learn more about your users and the problem space. ### Acknowledge the Unknowns You will not know everything in your first PRD draft, especially if you use some of the Minor Components. Mark those sections that require future research or decisions with placeholders like "To be determined." For example, if you're unsure about the technical feasibility of a particular feature, you might write "Technical architecture TBD pending engineering review." This transparency can foster a culture of openness and collaborative problem-solving. ### Collaboration is key Even in its early stages, sharing your PRD can spark valuable dialogue. Feedback from your team can validate assumptions, unearth new ideas, and help prioritize tasks. Don't be afraid to share your PRD early and often, even if it's not perfect. Remember, the goal is to create a shared understanding and get everyone on the same page, not to create a flawless document. This collaborative spirit is a key facet of a startup's agility. ## Closing Thoughts Before we wrap up, let's hammer home a few final points. Remember, a PRD is not a one-and-done kind of deal. It's a journey, a story that unfolds alongside your product. Embrace the twists and turns, the updates, and the pivots. Use your PRD as a tool for alignment, a springboard for collaboration, and a reality check when things start to go off the rails. But most importantly, don't let your PRD become a dusty old document that no one reads. Keep it fresh, keep it relevant, and keep it real. Share it with your team, listen to their feedback, and don't be afraid to make changes when needed. A good PRD is like a trusty sidekick—it's got your back through the good times and the bad. Finally, there are a handful of useful AI tools that can really help you create a PRD in no time. Check out [ChatPRD](https://www.chatprd.ai/?ref=productftw.com), find some [GPTs](https://chat.openai.com/gpts?ref=productftw.com) for ChatGPT, try [LennyBot](https://www.lennybot.com/?ref=productftw.com), or ask for help from [Claude](https://claude.ai/?ref=productftw.com). Work smarter, not harder! ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. Brought to you by the team at [Totavi](https://www.totavi.com/?ref=productftw.com). --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Determining the Problem to be Solved - ProductFTW #12 URL: https://www.productftw.com/productftw-12-determining-the-problem-to-be-solved/ Last updated: 2026-05-22T02:26:15.000Z Over the last few weeks, we’ve been chatting about how to [influence others](https://www.productftw.com/productftw-11-leading-without-authority-as-a-product-manager/) and get more work done when you know the problems you’re trying to solve and the things you’re trying to build. Today, we’re diving into some foundations, before you’re even ready to build something. Remember when Zach talked in [ProductFTW #4](https://www.productftw.com/productftw-4-being-the-first-product-manager/) about product strategy usually coming from the CEO? But what if that’s not the case? Where do you even begin? This is for the folks trying to build their product strategy who are either stepping into the PM role for the first time or hustling to build a product from the ground up. To start, there are two fundamentals to focus on: 1. What is the problem you’re solving? 2. Who are you solving for? ### What’s the problem? ![](https://www.productftw.com/content/images/2024/04/Question-marks.png) You probably have more questions at this point than you have answers. And that's okay. It is typically easier to find the problem, determine who the audience is, and prove that it is worth solving versus starting with the audience and looking for something to solve. I’m sure there is psychology behind this, but I will leave it to the experts and focus on the the former approach. We’ve all heard those success stories about people quitting college to build something from their parent's garage. But how did they decide what to build in the first place, and how did they get the courage or motivation to put everything in their life on hold to build it? I see it boiling down to three categories: - You’ve run into a problem yourself and feel it needs to be solved. - You’ve heard enough people venting about something that you’re convinced it’s up to you to tackle it. - A combination of one and two. To use me as an example, back in 2013, when I joined CreditCards.com, I was sitting on $30K of credit card debt. Talk about irony, right? I was trying to sell the perks of credit cards while personally, I was drowning in debt. It struck me how everyone was talking about points cards, yet nobody was focusing on getting out of debt or using credit wisely to turn things around. That’s what sparked my first venture, The Debt Girl. Think of it as The Points Guy’s counterpart, but all about getting your credit to work for you, not against you. That squarely put me in the first category, feeling the pinch and trying to solve a problem for myself. But was it a problem worth solving? ### Who’s the audience? To determine if the problem is worth solving, you start by identifying the target audience. This step, known as “quantifying the problem,” is about understanding how many people are struggling with this issue and the scale and depth of their pain. Several methods exist to compile this data, but it usually starts on the internet. There's a wealth of existing data online, including industry reports, consumer behavior studies, blogs, and more. Next, and sometimes the most daunting for us introverts, is the need to talk to people. Yes, face-to-face is best, but device-to-device communication can work too. This approach not only provides first-hand accounts of the problem and its impact but also gets you talking about the problem and potential solutions. The way you discuss your solution needs to resonate with your audience, and these initial conversations can be a great way to brainstorm ideas. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Sometimes, talking directly to people about the problem can be challenging. When I was pondering The Debt Girl, I knew how embarrassed I was to be in debt, and the idea of sharing my biggest secret with others, especially strangers (though sometimes that's easier), was daunting. It's definitely easier to have these conversations when you are directly experiencing what your target audience is because you're talking to them on the same level. If you find yourself in the second category (you’ve heard enough people venting about a problem that you’re convinced it’s up to you to tackle it), it doesn't hurt to do some research on how to discuss sensitive topics or to find someone who can speak on your behalf. There are numerous tools available to help assess the problem's relevance and intensity among your potential audience through surveys, interviews, and social listening. Platforms like social media, forums, and community groups can provide insights into how your target audience discusses and experiences the problem. Surveys, in particular, can help you not only determine the relevance of the problem but also gather direct feedback on your proposed solution. Your goal with all this research and conversations is to solidify who your solution is actually for and to develop a user persona. Think of a user persona as a detailed sketch of your ideal audience segment, pieced together from real data and stories. It’s a blend of what they want, the hurdles they face, who they are, and what influences them to make decisions, giving us a clear picture to keep in mind while we build things they’ll love. ![](https://lh7-us.googleusercontent.com/4yiW7IBbBcb4-aVBhOuNce-xXKXcPYFxxaBMm7cp6vnoGXnTKe138ullpoQPofN75GFckgRHgF_-1mLugLKWBVl4T29jCyKdAeRRRop03T25Qo8kfSd-EhrC3x5YIw3a29Lr0vjmX9X5BRo9Yonox1I) [Image from Alexander Gilmanov](https://uxplanet.org/user-persona-templates-that-will-make-your-life-easier-baee74ba5fc4?ref=productftw.com) I used to laugh at user personas. I thought they looked nice but didn’t really understand the practice of writing down who my target audience was and thought it was a waste of time. That changed when I started working on The Debt Girl. I thought my target would be anyone who was in debt, but as I started talking to people, I quickly realized there are many types of debt outside of credit cards and a lot of factors that go into someone getting into debt. I wouldn’t be able to give advice or information to every use case, nor should I. ### Validate your hypothesis Now that you know who you are building for, you need to validate your findings. There are many ways to do this without a lot of upfront investment, such as launching a minimum viable product (MVP), creating landing pages, or conducting pilot programs. These experiments not only refine your understanding of the problem and its significance but also gauge the market's readiness to embrace your solution. Throughout this process, you should continuously iterate based on feedback and new data. Your goal is to ensure that there is a significant, engaged audience for whom your solution not only addresses a genuine need but does so in a way that is economically viable. While I was going through this process, I launched a website, wrote articles, and promoted them on social media, gauging engagement. Over time, the feedback I received indicated people needed help budgeting, coming up with a plan, and understanding their options, a pivot from helping people leverage credit to get out of debt. In the end, whether you’re knee-deep in the problem yourself or stepping into someone else’s shoes to understand their struggles, the essence of product management lies in empathy, research, and iteration. It’s about believing in the problem you’re solving, the solution you’re building, and the people you’re helping. Remember, the journey of a product manager is not just about launching products but about creating meaningful solutions that resonate with and enrich the lives of your users. So, dive deep, keep learning, and always be ready to pivot based on what you discover. After all, the most impactful products are those that are built with purpose, passion, and a profound understanding of the human experience. But what if you’re a product manager and the CEO did set the strategy, and you haven’t experienced the problem yourself or seen firsthand how this problem impacts others? You can still be a great and empathetic product manager, but you need to believe in the product strategy and vision. Find the data, talk to the customers, live in the problem, and dig deep. Empathy isn’t something that happens overnight, and you are not a bad product manager if you are struggling. You need to find some proof for yourself that the problem is worth solving or move on. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### Leading Without Authority as a Product Manager - ProductFTW #11 URL: https://www.productftw.com/productftw-11-leading-without-authority-as-a-product-manager/ Last updated: 2026-05-22T02:07:27.000Z As a product manager, your success requires that a number of teams - engineering, design, marketing, just to name a few - work together in harmony, all marching to the beat of the same product vision. It’s your job to influence how resources are allocated and keep everyone focused on the most impactful initiatives to deliver the most product value to your customers. When conflicts arise, your role is to find solutions that keep everyone moving forward. And you need to do each of these without any formal authority or as a manager of any of the people mentioned. Simple, right? While it might not be simple, I believe it can feel less turbulent and challenging and make you more successful at leading without authority if you invest in developing relationships and how you approach influencing others. ![](https://lh7-us.googleusercontent.com/PcNbsTu9RrCd-nHc12AG38kb_EwLl7lS2r8q3287qyQXbyFDQcdCjk-ztzY0oJ3zcM8aWV9VcCt-Z8HJPePGZnxjGSQbkZXu_mziAnYK8kWsfuoy6kudnfOVaezS1yyOjgEIQltO4zqOw0JvBiMAcl4) Photo by[ Elijah Macleod](https://unsplash.com/@elijahmacleod?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) on[ Unsplash](https://unsplash.com/photos/influence-painted-black-metal-frame-during-daytime-9xaLKZvYxnA?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) Before diving into these, I want to say that there’s no one right way to be a product manager, and many different approaches and types of people can be successful in this role. That said, I think that leading without authority is one of the softer, more human, and empathy-driven areas of product management. There are certainly strategy and more initiative-focused things that you can do to be successful in this area, but building up emotional intelligence and your ability to connect with people will also take you very far. **Chief Storyteller** My communications and marketing background may be showing here, but I think one of the most impactful opinions that I brought to being a product manager was the importance of narrative building and storytelling. Building a product vision is important, no doubt, but communicating that vision in a compelling way that brings teams along with you is crucial. The ways to tell good stories apply in this context - use narratives, analogies, and maybe a little humor. All of the ways you would usually help people connect with the things you are trying to communicate can be applied to your work. I’m always looking for opportunities to tell good stories, in places big and small - from presentations to updates, in PRDs and user stories with well-considered personas and user journeys. I’ve found that when I’m diligent about keeping myself in this narrative mindset, it helps drives alignment across teams and also helps keep me focused as well. That said, I’m not saying that you should just be making up good stories. Data-driven decision-making and storytelling are both important, and the data should help you create your narrative. 💭 Remember, there's a difference between telling a story and telling people what to do. As a product manager, our role should never be based on telling people what to do but rather on working alongside our teams to accomplish our goals. **Chief Listener** Listening and empathizing are also key components of leading without authority - the more people feel like you listen to them, the more likely they are going to be willing to listen to you. Actively listening to team members’ concerns, ideas, and feedback and striving to understand their perspectives will not only help you build connection and empathy, but you will most certainly learn and improve along the way. This is one of the places where product and engineering 1:1s were really impactful for me. How often I had these 1:1 meetings was driven by how many engineers were on my team, but I always made sure they happened at a bare minimum of once per month. These meetings were consistently the place where I was able to address interpersonal issues, understand external factors that may impact productivity, and generally hear about concerns or issues related to team dynamics or our work. And it was my follow-through on the things I heard in these conversations that helped build trust. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. **Cultivate a Collaborative Environment** As a product manager, you're not just a leader but also a facilitator and a bridge between different teams. You should encourage open communication and create platforms for cross-functional collaboration, such as brainstorming sessions or project check-ins. At Wallaby, we made an event out of end-of-sprint demos for the broader teams to see what we were working on. We made them fun with drinks and snacks, and would often follow them with something lighthearted like a foosball tournament or games. On a more serious note though, they were a place for other team members to engage with what was coming down the pipeline, ask questions, and I often would come away from those with notes about team members outside of our sprint team that I should be reaching out to or new feedback to consider. Even small practices like demos can give your whole team a sense of ownership and investment in the product’s success. By cultivating a collaborative environment, we not only built a stronger and more cohesive team, it felt like we were able to unlock more of the full potential of our collective skills and expertise - which ultimately led to us shipping more consistently. 💡 Even when the things you are doing may feel minor, the effort to create these opportunities to collaborate contributes to the respect and trust needed to lead your team and product to success. **Celebrate Wins** Don’t forget to celebrate wins, both big and small. In the hustle and bustle of startup life, it's easy to overlook achievements. Take the time to recognize your team’s successes, whether it's through a nice email or a shout-out in a meeting; celebrating victories boosts morale and keeps your team motivated. Making sure that I was asking for budget to buy the team lunch or doing something that felt special to celebrate went a long way to making team members feel appreciated. (You should be doing more than just buying lunch to make sure your team feels appreciated.) And celebrating together has always helped my teams feel more connected to each other, as you know…people. The times when that connection has broken down or had been strained, there was noticeably more resistance in meetings, in planning, and in our work. **Put it all Together** Great, so we’re telling stories, listening, collaborating, and celebrating. How does that turn into leadership? Leading without authority is about the impact you make and the relationships you build to influence progress effectively. Through your actions, empathy, and dedication to the team and the product, you’re helping to create a team that is motivated, engaged, and ready to take on challenges together. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### How to Get the Team to Estimate - ProductFTW #10 URL: https://www.productftw.com/productftw-10-how-to-get-the-team-to-estimate/ Last updated: 2026-05-10T23:39:49.000Z In [ProductFTW #9](https://www.productftw.com/productftw-9-technical-debt-features-and-time-management/), we explored how accurate estimations can prevent burnout and frustration. It's important to clarify from the outset that, as product managers, we don't perform the estimations ourselves; rather, it's the engineers who estimate the time and effort required for tasks. Our role involves understanding, facilitating, and utilizing these estimations to communicate with stakeholders, plan roadmaps, manage dependencies, and set overall expectations. Without accurate estimations, executing our role effectively can be challenging. So, why are we even writing this post? Your primary role is to deliver the product exceptionally and reliably. To achieve predictability, the engineering team needs to execute your plans with precision. I don’t know a single engineer who would volunteer to estimate their work. They often require encouragement, sometimes even pressure, to make estimations. In startups and smaller companies, this task of persuasion frequently falls to the product manager, who balances collaboration and enforcement with the engineering team. Talking about estimations can spark a bit of a debate. Every place I've worked, it's the same story: engineers see it as a nuisance, a distraction, even calling it a SWAG (scientific wild-ass guess). But here's the thing: we're aiming to turn those wild guesses into something a bit more solid and backed by data. We've got to start somewhere, right? ![](https://lh7-us.googleusercontent.com/20HB6ALCcUr51K7lMSC3-lZc6Flkr-_zU9MkOf1mfU09tZ5KWIZdNppVzbjtaeoD1RSbd6KulGFZZELMHuXfFNx5xqrfaszYTjRckfFqti7yZoPzuer2IZYj8PcJpES12EZ1nSfy6ORLYFpvnNuiECg) This is the look every engineer has given me when I mention estimations. Engineers aren't fans, and I get it. They're all about accuracy, and estimations just don't fit that bill. It feels like going against the grain. No team I've been part of was ever thrilled about it, and the smaller the team, the louder the groans. But despite the pushback, sketching out even a rough timeline is non-negotiable. It’s not just about us in tech; it’s about the entire company working together in sync. I’d like to think that the mention of estimations makes engineers momentarily forget that there's an entire team outside of technology that relies on our guesses to plan and execute their own work. Without us providing some form of timeline, the marketing team is left in the dark about when to align PR efforts, set teasers, or even draft copy. Similarly, the sales team can't set realistic expectations with prospects, potentially leading them to make promises we can't fulfill. The list of people and teams that rely on estimations can go on and on because they really are that important. So, the question is, how do we build the data behind the SWAG? We need to get organized and select a framework for measurement. The biggest challenge is getting everyone on board with whatever framework they choose. It's about making sure everyone's on the same page and agrees on what each estimate means. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ### Some Popular Estimation Frameworks **Planning Poker** Planning Poker combines consensus, gamification, and the wisdom of the group to make estimation more accurate and engaging. It avoids the influence of the loudest voice in the room and encourages everyone to contribute, making it a democratic way to reach a shared understanding of task sizes. **How it Works:** - Each team member gets a set of cards, each representing a different level of effort (typically using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, etc.). - A user story or task is presented, and after a brief discussion, each member selects a card representing their estimate of effort. - All cards are revealed simultaneously. If estimates vary significantly, a discussion follows to understand different perspectives. - The process is repeated until the team reaches a consensus. 💬 For the record, Matthew hates Fibonacci sizing 😉 **T-shirt Sizing** T-shirt Sizing simplifies the estimation process by categorizing tasks into sizes from XS to XXL, making it an accessible approach for all team members. It's particularly useful for high-level estimations or when detailed information might not be available, promoting relative comparison over exact time frames. **How it Works:** - Tasks are estimated based on relative size categories (e.g., XS, S, M, L, XL, XXL) instead of specific time units. - The team discusses each task and agrees on a size that best fits. - This method is often used for high-level estimation, especially in the early stages of planning. **Bucket System** The Bucket System is a fast and efficient method for estimating a large number of items by grouping them into predefined buckets of effort or size. It encourages relative thinking and is dynamic, as items can be moved between buckets as discussions progress and consensus is formed. **How it Works:** - A set of buckets is created, each representing a different level of effort or size (similar to the categories used in Planning Poker or T-shirt sizing). - Each task or story is discussed briefly, and then team members place them into a bucket. - Tasks can be moved between buckets as the team discusses and reaches a consensus on their relative effort or size. **Big Rock/Small Rock** The big rock/small rock system attempts to minimize sizing effort, with the ideal ensuring a sprint has a bit of extra room and nothing spills over. Picture a bucket and see one big rock inside, with a series of small rocks. This can work especially well in a sprint team with a variety of cross-functional engineers, but giving a primary story (big rock) to each engineer by specialty (e.g., data, mobile, API, etc.). **How it Works:** - Engineers size tickets based on their expertise or planned assignment into big vs. small - Depending on how your team sizes this, each engineer can only do one big story per sprint and then 3-5 smalls. This process aims to ensure that committed tickets are completed but leaves more uncertainty. As a product manager, you must have a well-groomed backlog, as this often leads to some additional capacity to bring in extra tickets. The “spaces” left in the bucket are for urgent fixes or mis-estimations. ![](https://lh7-us.googleusercontent.com/PHQJt9SsgzFPbshb7d0W1mcAbux24hBiw7jopAZTYgcKHS4-FouwwZ7Tk5XjhhJcUWudtMNbJ7peYhp6SVAPvjTFau5anQByv6s9rJ4ApdJqN6zKYyXtOBzyTAsb6Yjsk_IFk_P5jmvhlBDfFBJuvJ0) Just a bucket of rocks. After choosing a framework, go through the last few months of tickets and size them up. This acts as your baseline. Yes, there will be debates and adjustments, but that’s part of the process. Getting everyone aligned on what the sizing actually represents is key. Next up, size the stories for your upcoming sprint. Post-sprint, take a hard look at how accurate those sizes were. It’ll be messy at first – expect that. What you’re digging for is the 'why' behind any misestimations. Were there unforeseen dependencies? Was there complexity or an external factor like techops alignment that could have been planned better? This is your chance to learn and adjust for future sprints. Recognizing these patterns helps refine your approach to estimations and planning, especially in accounting for those dependencies and complexities earlier in the process. 🚩 The temptation to blame the framework and switch it up will be strong. But resist it (for at least three months). The framework isn’t the issue; it’s about how you use it and learn from it ![](https://lh7-us.googleusercontent.com/hsHSHQUpPoCvv5j7m0NNP9QLJ5B9BZJ10w6YAMku8l1a2yMEMlG3CpA1XhuhvFNNLZjdPAZqen9NDQwPyWOtz-7ADd-kv0iwSSHM77sfFG8zykO8F9rewFTIuvj2P0KFcKawQr3HTp-Sc_ilrcbcPUI) Add two weeks... or three... or four. As the product manager, your role is to keep the team on track, encourage reflection on what didn’t go as planned, and document accurately estimated items for future reference. And yes, there’s a bit of a product manager’s insider tip: whatever the engineering team’s estimation, tack on an additional two weeks. This isn’t just for laughs; it’s practical advice. Even when you start to trust the team's estimations, those extra two weeks can be a lifesaver for handling the unexpected. Always aim to overdeliver, not underdeliver. ## About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Technical Debt, Features, and Time Management - ProductFTW #9 URL: https://www.productftw.com/productftw-9-technical-debt-features-and-time-management/ Last updated: 2026-05-10T23:39:47.000Z ![](https://www.productftw.com/content/images/2024/03/morgan-housel-X_fbh4Utwk4-unsplash.jpg) Photo by[ Morgan Housel](https://unsplash.com/@morganhousel?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) on[ Unsplash](https://unsplash.com/photos/person-holding-yellow-round-analog-clock-X%5Ffbh4Utwk4?utm%5Fcontent=creditCopyText&utm%5Fmedium=referral&utm%5Fsource=unsplash) A frequent point of debate between product managers and technology development teams focuses on the allocation of time between developing new features and maintaining existing products. Development time, particularly in startups, is a limited resource that depends heavily on team size and must be carefully managed and allocated. In this post, we explore a framework for approaching this challenge. New features often generate excitement, drive growth, enhance products, and attract considerable attention. In contrast, maintenance, or addressing technical debt, tends to be viewed as less glamorous, not directly contributing to new capabilities, and often regarded as a tedious necessity. Much like many things in the world, software requires upkeep. Although not literally true, I frequently liken software to a living entity that requires care and attention. Even without the introduction of new features, software naturally degrades over time. Emerging security vulnerabilities, minor bugs, memory leaks, and other issues can compromise application stability, necessitating maintenance efforts. I once met a Ph.D. computer science researcher who posited that predicting code errors was as simple as examining code deployment frequency. The more code you produce, the more issues arise. While this may seem obvious, the underlying truth is that any interaction with your application can introduce problems. Technical debt has become such a widely recognized issue that mainstream publications like the *Wall Street Journal* have discussed it, describing it as "[The Invisible $1.52 Trillion Problem: Clunky Old Software](https://www.wsj.com/tech/personal-tech/the-invisible-1-52-trillion-problem-clunky-old-software-f5cbba27?ref=productftw.com)." Technical debt refers to the future cost incurred by opting for an easy, quick, or limited solution now instead of a more comprehensive approach that would require more time. Similar to financial debt, technical debt accrues interest, meaning the longer it goes unaddressed, the more it can impede future development by making the codebase increasingly challenging and time-consuming to modify or extend. Various factors, including rushed releases, a poor understanding of requirements, inadequate testing, or the use of outdated technologies, can contribute to technical debt. Effectively managing technical debt is vital for the long-term health, scalability, and maintainability of a software project. In extreme cases, as highlighted by the WSJ and often discussed at Bankrate, the accumulation of technical debt may necessitate declaring "technical bankruptcy" and starting anew with a complete rewrite, significantly disrupting the development of new features. Given the significant impact of technical debt, it's crucial to thoughtfully allocate development time. Product managers (PMs) might initially expect 100% of a developer's time, equivalent to 40 hours per week, to be available for new features. However, this approach can be a recipe for disaster. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Instead, I advocate for teams to plan for only 50-60% of a standard workweek to be dedicated to new feature development and functionality work. Additionally, 15-25% of each week should be reserved for maintenance, refactoring, and addressing technical debt. The remaining 15-25% should be allocated for overhead tasks such as training, company meetings, primary research, and development. Balancing the demands of developing new features with maintaining existing products relies not just on how we allocate our time but also on our ability to make and refine accurate estimates. A common pitfall for many teams, especially in startups, is either underestimating the complexity of tasks or overestimating their team's capacity. Estimating incorrectly leads to scenarios where teams are unwittingly setting themselves up for failure, working unsustainable hours, or, conversely, not completing planned work due to optimistic scheduling. Accurate estimations are essential to avoiding burnout and frustration. We can better manage the delicate balance between innovation and maintenance by initially setting realistic expectations and then continuously refining these estimates based on actual performance and outcomes. The iterative process of estimation and adjustment allows teams to become better at forecasting their capabilities over time. It's a learning curve that requires patience, persistence, and a willingness to adapt. By doing so, we not only honor our commitment to deliver high-quality products but also respect the well-being of our team. It’s about creating a sustainable development rhythm that accommodates growth, innovation, and the inevitable unpredictability of software development without falling into the trap of overcommitment. By entering sprint planning with a balanced approach to time allocation, product managers can more effectively produce high-quality products quickly because they are: - Making more reliable plans by accurately accounting for the time required for new features - Investing in stability because while new features may attract users, instability can drive them away - Providing developers with opportunities for training, growth, and innovation - Showing respect for the solution development process 💡 A common mistake among early-career PMs is the urge to deliver as much as possible, as quickly as possible. While we admire companies known for their rapid delivery, speed in shipping does not come from overloading sprints or overworking developers. I serve as an advisor to a company undertaking similar initiatives to those I pursued at Wallaby. The founder once remarked, "Wow, you accomplished so much at Wallaby in such a short time with so few people." Indeed, our team was small, comprised of one mobile engineer, one services engineer, one backend engineer (who also served as the CTO), one data/DevOps engineer, and one user experience designer, with occasional support from a contract web engineer. Our achievements, including launching mobile applications on Apple and Android, a web application, a Chrome extension, and more, were not the result of working 90-hour weeks. Rather, they were due to having clear objectives, valuing time off, and committing each sprint to maintenance. # About ProductFTW [*ProductFTW*](https://www.productftw.com/) is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. ### Is it Wrong to Use AI to Assist with Product Management? - ProductFTW #8 URL: https://www.productftw.com/productftw-8-is-it-wrong-to-use-ai-to-assist-with-product-management/ Last updated: 2026-05-10T23:39:46.000Z For the past few weeks, we’ve been sharing about [what a product manager is](https://www.productftw.com/productftw-1-what-is-a-product-manager/), [what your first few months should look like](https://www.productftw.com/productftw-4-being-the-first-product-manager/), and [how to build skills like communication](https://www.productftw.com/productftw-6-how-to-effectively-communicate-as-a-product-manager/) and [confidence](https://www.productftw.com/productftw-7-building-confidence-in-saying-no/). In this post, we're shifting gears and sharing some insights and reflections about AI from a sit-down interview I did with Zach. Before diving in, let me provide some context to bring you up to speed: Back in 2022, Zach and I were co-leading a remote product team. On Fridays, we made it a point to gather the team for a social hour. More often than not, these gatherings turned into spirited debate sessions—after all, who doesn't enjoy defending their views passionately amongst peers? At the time, one of our team members (shoutout to Dan!) had a keen interest in ChatGPT. As we all began exploring its capabilities, we found ourselves engrossed in discussions about its potential impact on our careers, as well as the moral and ethical considerations its use entails. Fast forward to the present, and it seems nearly everyone I know incorporates some form of AI into their daily professional life. Remarkable how much can change in two years, isn't it? We, the team behind ProductFTW, are enthusiastic proponents of AI. Zach, in particular, was so captivated by its potential that he transitioned from a career in fintech to joining an AI startup, Perigon. Perigon predated ChatGPT, initially focusing on distilling news content to its essence and reporting the facts without superfluous detail. As AI gained traction, Perigon recognized an opportunity to leverage its existing infrastructure for more efficient data analysis. I thought it would be enlightening to sit down with Zach and discuss his perspectives on product management and AI. We’ll explore how product management will evolve with AI, if it will replace product managers, and if relying on AI to perform job functions is ethically questionable. Let’s dive in. ![](https://www.productftw.com/content/images/2024/03/zach-ellen-2.png) Meet Ellen and Zach! **Ellen:** How have your thoughts on product management and AI evolved since moving from Fintech into AI? **Zach:** I’m still amazed at what it can do, and I understand the limitations. When ChatGPT first came out, it blew everyone’s mind. But when you tried to use it practically, like to draft an email, it was terrible. This is still true today. The more you work with the tools, the more you realize the limitations, but it is evolving every day. Ultimately, AI won't replace the human creativity and strategic oversight required in product management. Instead, it enhances our capabilities, making us more efficient and allowing us to achieve more with less. It's an exciting time to be in product management, as AI opens up new horizons for innovation and efficiency. **Ellen:** When using AI tools as a product manager, what should you look out for/what are the blind spots? **Zach:** For product managers utilizing AI tools, vigilance is necessary. Trust, but verify: - AI's outputs should not be taken at face value; always double-check. - Consider the level of detail provided. - Assess the factual basis of the information. - Validate every piece of data. - Reflect on potential oversights or unaddressed aspects. **Ellen:** How has AI changed how you develop and adjust your product strategy? **Zach:** It acts as an additional intelligent voice, offering instant feedback that helps identify gaps, missing elements, and considerations I might have overlooked. This is especially valuable in smaller companies where the product management role can sometimes feel isolated. It's easy to become trapped in an echo chamber without diverse input, but AI helps break through that by providing a broad range of insights and perspectives. Essentially, it's like having a highly efficient, data-driven partner in the strategic planning process, enabling a more dynamic and responsive approach to product development. **Ellen:** How do you see AI impacting the product development lifecycle? **Zach:** AI is set to significantly accelerate the entire product development lifecycle. From the initial analysis phase, where we feed in data to understand trends and patterns, to the decision-making process about which concepts to pursue. AI can drastically reduce the time it takes to analyze vast amounts of data, providing insights that would have previously taken weeks or months to uncover. AI's role in automating routine tasks cannot be understated. It can handle aspects of design, testing, and even some elements of coding, which speeds up the development process. This doesn't just shorten timelines; it also allows product managers and their teams to focus on more strategic and creative tasks, pushing innovation further. In the context of product strategy, AI enables a more agile approach. We can quickly pivot based on real-time feedback and data analysis, ensuring that the product remains aligned with user needs and market demands. This dynamic capability to adjust and refine our strategies is a game-changer, making product development more responsive and efficient. ## Sign up for ProductFTW A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. **Ellen:** Will AI automate product managers out of their roles? **Zach:** The short answer is no, AI won't automate product managers out of their roles. However, it will redefine what those roles entail and how we approach our work. In the future, we might see fewer product managers, but their roles will be more impactful. They will manage broader areas and oversee more complex projects, thanks to AI's assistance in analyzing data, generating insights, and automating routine tasks. Consider large companies like Facebook, which employ hundreds of product managers for individual features. With AI's help, a single product manager could oversee what a whole product team oversees today, as AI can take on the role of a product analyst and handle tasks that are currently time-consuming for humans. Product management is about understanding market needs, envisioning products that meet those needs, and guiding teams to bring those visions to life. These core aspects require human intuition, creativity, empathy, and strategic thinking—qualities that AI cannot replicate as of yet. AI can provide tools and insights, but it cannot replace the human touch that is essential for successful product management. Furthermore, the evolution of AI will likely see product managers becoming more skilled in working alongside AI, using it to enhance their capabilities rather than being replaced by it. Product management has always adapted to technological advancements, and AI is just the latest frontier. **Ellen:** How will the career path for a product manager look in the future? **Zach:** We discussed earlier how there might be fewer product managers, but those who remain will be more impactful, managing broader areas and more complex projects. This implies that the career path will likely emphasize depth of experience and expertise in specific industries or technologies. Product managers will become more specialized, but at the same time, they'll need to maintain the flexibility to adapt to new tools and methodologies. Additionally, the entry points into a product management career might shift. Currently, many product managers come from diverse backgrounds, including engineering, design, marketing, and even customer support. In the future, we might see a stronger emphasis on direct experience with AI and data-driven decision-making as prerequisites. However, hands-on experience and the ability to demonstrate strategic thinking and leadership will remain key. **Ellen:** Do you think it is wrong to use AI to produce product management artifacts such as requirements documents? **Zach:** Absolutely not. It is no different from using any other tool that enhances productivity and efficiency. It's akin to asking whether it's wrong to use a computer to type up documents instead of a typewriter. The essence of progress in any field, including product management, is to leverage the best tools available to achieve your goals more effectively. AI tools are designed to assist in streamlining complex tasks, processing large data sets to provide insights, and even drafting initial versions of documents that can save a significant amount of time. This enables product managers to focus on higher-level strategic planning and decision-making rather than getting bogged down in administrative tasks. **Ellen:** Where is the line between getting credit as a PM and giving credit to AI? **Zach:** The real value that product managers bring to the table is not in the routine tasks that AI can automate but in their ability to synthesize information, make strategic decisions, lead teams, and drive the product vision forward. This involves interpreting AI-generated insights in the context of the market, making judgment calls based on incomplete information, and navigating the complex interpersonal dynamics of product development teams—areas where AI currently cannot replicate human capabilities. Zach and I thoroughly enjoyed our trip down memory lane, reminiscent of our Friday social hours. We're eager to hear your perspectives on these topics. Whether you agree, disagree, or have additional insights, we welcome your thoughts. 💡 This entire post was edited by ChatGPT. ### Building Confidence in Saying "No" - ProductFTW #7 URL: https://www.productftw.com/productftw-7-building-confidence-in-saying-no/ Last updated: 2026-05-22T02:07:29.000Z This week, I want to dig a little deeper into a topic Ellen touched on in [our last post](https://www.productftw.com/productftw-6-how-to-effectively-communicate-as-a-product-manager/): the product management mantra that you should say “no” more than you say “yes.” It was certainly the first big lesson Matthew instilled when he hired me as a product manager at Wallaby–which felt especially uncomfortable for me at the time because it was my first time in a PM role. I didn’t feel like an expert in anything yet, and I had built my early career and reputation by saying “yes.” There are countless posts about the importance of saying “no” and tips on how to do it more confidently (on which I’ll also give my two cents below), but I think what many people miss in the conversation is helping those of us in product roles turn inward and first talk about why it's so hard and how confronting it can be so that we can build our confidence and this skill more holistically. ![A woman's hand holding a heart-shaped Valentine's cookie that reads "xox-no"](https://www.productftw.com/content/images/2024/02/premium_photo-1675857197778-223b59de19fe.jpeg) Photo by [Amy Shamblen](https://unsplash.com/@amyshamblen?ref=productftw.com) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) **Why can it be difficult to say “no”?** 1. **Fear of conflict:** As product managers, we work at the intersection of various stakeholders horizontally across functional teams and vertically through many levels of the organization. We often have to lead through influence and relationships, so saying “no” can and likely will lead to conflict at times, which can feel scary, destabilizing, and potentially damaging to the relationships we rely on. In general, addressing any fear of conflict you may struggle with is an important part of being a strong product manager and leader. 2. **Managing our professional image and expectations:** Product managers are often facilitators of progress and enablers of ideas. Saying “no” can sometimes be perceived as being unhelpful, obstructive, or negative and create some cognitive dissonance when we want to be seen as a cooperative and supportive colleague. In our role, we are often measured by our ability to deliver, and “no” can feel like the opposite of delivery. Always saying “yes,” though, comes with the same risks if you can’t actually deliver on your commitments. 3. **FOMO:** In the often fast-paced startup environment, saying “no” to a feature or project might mean missing out on a potentially successful outcome. We work to build a product vision, to prioritize and be strategic, and there may still be the fear that the vision, priority, or strategy could be missing something that could lead to our product’s big moment. 4. **Pressure to perform:** The role of a product manager often comes with high expectations for success and innovation, and with that, a feeling of pressure to perform and please all stakeholders, making it challenging to say “no,” especially if it’s a feature or initiative being pushed by influential team members or leaders. You will never be able to please every single stakeholder and team member, and that’s ok. 5. **Optimism bias:** As with any unconscious bias, we can all be susceptible to their impacts when we aren’t doing work to confront them. There’s an amount of optimism everyone needs to work in a startup, especially when we are in the 0 to 1 phase of the business, perhaps as the first product hire in your company, but there’s a point that it can go too far and lead us into overcommitment. ![](https://www.productftw.com/content/images/2024/02/Feature-Request-Incoming-768x768.png) Comic by [Work Chronicles](https://www.workchronicles.com/?ref=productftw.com) **You can’t outrun “no”** In my own experiences, there were certainly projects and times when I should have said “no,” but because of the pressure I felt (external or internal) or that optimism bias sneaking in, what I learned from those is that while saying “yes” upfront may have felt easier, they always caught up to me. Whether it was having to push a launch date or cut features, saying “yes” when I shouldn’t have only delayed having to experience the same feelings I was trying to avoid. Those feelings were then also paired with me having to take ownership of the fact that we were behind or overcommitted. **Building your “no”** **confidence** A few insights and things to keep in mind that I think are helpful when trying to get more comfortable in saying “no”: 1. **Focus is key**: Resources are finite, particularly in startups, and one of our most important jobs as product managers is to drive focus on our teams. Saying “no” helps focus your often limited resources effectively, ensuring that you’re working on what truly matters and can deliver on your commitments. Keeping this in mind can help build your confidence and also help you communicate across the organization why you’re making trade-offs or saying “no” to something. 2. **Clarity leads to credibility**: Initially, in my own career, I worried about the repercussions of saying “no,” particularly to leaders and executives who were often the founders and original product managers for the products on which I was working. However, clarity in decision-making builds your credibility and trust with your leadership team by demonstrating that you have well-thought-out strategies and understand the needs of your customers and the business. 3. **Prioritization takes courage:** Again, saying “yes” can seem like the path of least resistance, so saying “no” requires courage to make very tough decisions for the greater good of the product or team. The way that you build courage is by acknowledging the things that might feel scary and making the conscious choice to face them, building the muscles and resilience to do hard things more easily and more comfortably each time you do them. 4. **Not right now doesn’t mean never:** It's important to remember that “no” is often temporary. Prioritization is about timing and relevance, balancing the short-term needs, time, or constraints with the capacity of your team and what’s going to deliver the most value to the business goals. This is part of why you keep a backlog so that you can say “yes” to ideas when they better align with your strategy. Reminding the team or stakeholders of this can also help you when you deliver a “no” that they might not want to hear. 5. **Remember to have empathy:** Product management calls for empathy in many things and for many people simultaneously - your customers, your team, and your stakeholders. Understand and acknowledge the merit in the feature you’re declining and explain your rationale so that leaders or teams that are impacted by your decision understand why your “no” is important. Empathy, coupled with some of the tips that Ellen covered last week about [effectively communicating](https://www.productftw.com/productftw-6-how-to-effectively-communicate-as-a-product-manager/), like being direct, documenting your decision-making, and practicing, can go a long way in building credibility and rapport even when delivering hard news. Embracing "no" isn't about shutting down ideas; it's about sharpening your focus on the projects that truly resonate with your goals and driving value for your customers and the business. It's a skill that's rooted in bravery and a clear-eyed view of your priorities. If there's one thing my journey has taught me, it's that every "no" makes room for a "yes" that can genuinely make a difference. So, I'm curious—how have you tackled the art of saying "no" in your role? Were there things that made it hard for you at times, and how did you overcome them? We’d love to hear any stories or tips you're willing to share in the comments. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### How to Effectively Communicate as a Product Manager - ProductFTW #6 URL: https://www.productftw.com/productftw-6-how-to-effectively-communicate-as-a-product-manager/ Last updated: 2026-05-22T02:07:28.000Z Over the last few weeks, we’ve explored [what a product manager](https://www.productftw.com/productftw-1-what-is-a-product-manager/) is and its role and responsibilities. One of the core themes has been communication. 💡 **When I refer to communication, I mean listening, writing, and speaking.* As a product manager, your role fundamentally involves accurately interpreting your customers’ needs and transforming them into clear, actionable tasks for your development team. It’s like an ongoing game of telephone; any lapse in listening, interpreting, or communicating can adversely affect your product. It turns out that communication is something we do all the time, but it isn’t something we often practice to improve. I remember when I started my PM career, I was terrible at synthesizing my thoughts and putting them on paper, and I wasn’t self-aware enough to know I was terrible. My engineering lead at the time (Hi, Mitchell) suggested we get a coffee and give each other a little evaluation since we were peers and not getting much feedback from management, and we both wanted to keep accelerating in our careers (something I highly recommend to everyone). During this session, he provided examples of when my ineffective communication had impacted the team. Fast forward a few years later, Mitchell gave me one of the biggest compliments of my life. He told me I could walk into any room, with any audience, and immediately command it. I was in disbelief, but over time, I realized that this was the perception of my peers because I had become an excellent communicator. My job title put me in a position where there was very little room between me and company leadership. It was my job to ensure we got shit done (GSD). ![](https://www.productftw.com/content/images/2024/02/DALL-E-2024-02-21-13.38.40---A-professional-setting-with-a-diverse-group-of-individuals-sitting-around-a-large-table-filled-with-laptops--tablets--and-notes.-In-the-center--a-pers.webp) It is not recommended you stand on a table to command a room at work. So, how did I improve my communication to a commanding-a-room level? Practice. As the saying goes, practice makes perfect, and communication is something that needs to be practiced almost every day. Here are ways you can practice: ### **Documentation** *Document everything.* Documentation is an art. It is incredibly challenging to document something that will make sense to someone who wasn’t present, or that will be relevant in the future. However, doing this well will ensure you don’t have duplicative conversations or, worse, revisit decision-making. Time is money. As a product manager, you’re deeply involved in every facet of your product and at the center of all communication channels. You must ensure that every decision, meeting outcome, and significant interaction is documented and effectively communicated to relevant parties. The approach you take to document and share these details is entirely up to you, and it might vary based on your unique PM style (we will discuss PM styles in a future post). The way I approach this is by asking myself, “If I wasn’t present at the meeting, or had little to no context on the topic, would I understand it by reading my documentation?” ## **Ask Questions** *Ask at least three questions, even if you believe you already know the answers.* ![](https://www.productftw.com/content/images/2024/02/DALL-E-2024-02-21-13.45.55---A-simple-and-humorous-stick-figure-cartoon-set-in-a-meeting-room.-The-scene-shows-a-stick-figure-standing-up-at-the-end-of-a-long-table--surrounded-by.webp) There are a lot of unhappy people in this room. Now, don’t be that person who sits at the table and asks questions that detract from the topic or try to be the most intelligent person in the room. Instead, ask questions to guide your peers into being more effective communicators or challenge their opinions. We all win together. This also applies to your customers and stakeholders. As a PM, you will need to listen to your customers or stakeholders and translate those into specific requirements. However, how can you truly know the actual needs of the customers or stakeholders if you don’t ask questions? You are only making assumptions. As the familiar saying about assumptions reminds us, this often leads to misunderstandings. ## **Be a Parrot** *“Do you mind if I repeat that back to you?”* This simple question can be a powerful tool in ensuring effective communication. Parroting, or repeating back what someone has said in your own words, serves multiple purposes. Firstly, it confirms that you have correctly understood the speaker’s intent, which is crucial in avoiding misinterpretations. Secondly, it provides an opportunity for the speaker to clarify if there’s any discrepancy between what they said and what you understood. But how do you implement this technique without sounding repetitive or like you’re not paying attention? I suggest listening carefully, rephrasing for clarity, and seeking confirmation: “Did I understand that correctly?” ## **Be Direct** *Give direct feedback & answer questions clearly and concisely (then provide additional context if necessary).* Less is more in a professional setting (and perhaps a personal one). I am not suggesting you give less feedback, output, etc. You should give it your all, but be focused and efficient. When giving feedback, don’t sugar-coat it. Be direct. Have you ever had a manager provide you with feedback that wasn’t clear, and you couldn’t understand how you could improve? This is what I am talking about. It is not a learning experience to figure out your manager’s feedback. It’s a waste of time, and you’ll likely never meet their expectations. You learn if your manager sets out very clearly what they expect, so you can quickly react without confusion and a bunch of trial and error. Being direct applies to your product work, too. You will be asked a lot of questions, such as “When will the team deliver this feature?”, “What is on the roadmap?”, “Does the team have the capacity?” and many more. As a product manager, you’re deeply involved in the various complexities of your product and team. While your initial reaction may be to share all details, doing so can lead to confusion and even mistrust. People need to see you as a reliable source of information and trust your insights as the voice of the product. If you consistently respond with lengthy explanations, there’s a risk that your coworkers might seek information elsewhere or draw their own conclusions. ## **Say No** *Say no more than you say yes.* ![](https://www.productftw.com/content/images/2024/02/DALL-E-2024-02-21-13.38.35---A-humorous-cartoon-scene-featuring-a-product-manager-and-a-software-developer.-The-product-manager--depicted-in-an-exaggerated--cartoonish-style--is-s.webp) That is definitely out of scope. It is easy to say “yes.” Saying yes makes everyone feel good. But saying yes to everything means nothing gets done. Every product manager must embrace saying “no.” It’s not about being uncooperative or unfriendly but protecting your team and the product. Regardless of your company’s size, you have limited time and resources. Having unresolved edge cases is OK because you must be hyper-focused on delivering the highest-impact features. Saying “yes” is a strategic decision that must align with the product’s overall vision and goals. ## **Practice, Practice, Practice.** Mastering the art of communication is not going to happen overnight. It is something you will refine and adapt over your career. Remember, the goal is not just to convey information but to do so in a way that is clear, impactful, and aligns with your team and stakeholders’ needs, and when your team grows or you change roles, you will have to adapt again. Reflect on your interactions, seek feedback, and remember that every great communicator was once a beginner. Your ability to articulate visions, needs, and feedback clearly is your superpower as a product manager. I would love to hear about your experiences and tips in the comments below. How have you improved your communication skills? Let’s learn from each other and continue to grow. Here’s to speaking our way to success, one clear, concise, and constructive conversation at a time. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Being the First Product Manager Part II - ProductFTW #5 URL: https://www.productftw.com/productftw-5-being-the-first-product-manager-part-ii/ Last updated: 2026-05-22T02:07:21.000Z 🚧 If you haven't read part 1, click [here](https://www.productftw.com/productftw-4-being-the-first-product-manager/) to get caught up. Remember that first week on the job? Remember getting blasted by that firehose of information and the overwhelming feeling that you might never get a handle on things? Well, get used to that feeling–it’s part of the fun! During your first month, you put together a rough strategy, took a stab at a roadmap, and introduced some light processes. Now’s not the time to rest, though–things are just getting started. In Part 2 of Being the First Product Manager, we identify what to focus on after that first month and how to use continuous evaluation to make smart decisions to maximize your success as the OG PM. Let’s get out the raincoat and dive in. ![Firehose spraying a person in the face](https://www.productftw.com/content/images/2024/02/Artwork-5.png) Refreshing! # After the first month Alright. You’re 30 days in and getting the hang of things. You know your customers, the value your product provides, and the short to medium-term focus of the company. You’re vibing with the team, you have several new features lined up, and you know how you’re going to measure your success, right? No? Well, don’t stress yet- this shit is hard. If you are, in fact, crushing it, you rock! With the strategy, roadmap, and process in hand, you can turn your attention to the core of product management- talking to customers, building solutions to their problems, and then measuring the impact of those solutions. How well you do that all depends on your product strategy and ability to execute. As you start getting some product cycles in, you should be evaluating the following aspects: **Feature launches–**Evaluate the success of each product feature release by considering the following: - User adoption: Do people use the feature, and how frequently? If not, is it a discoverability issue, or is there a fundamental flaw in the feature’s value prop? - Strategic Alignment: Does this feature move the needle on your product strategy and broader business goals? If it doesn’t contribute to broader goals, it might need adjusting. - Metric impact: What effect does this feature have on your core metrics? Watch for vanity metrics (looks good but doesn’t drive sales, retention, etc.) vs. genuinely impactful ones. It’s okay if your original product strategy isn’t working out like you expected as long as you can understand why it’s not working. Now is the time to figure out if you need to pivot, so if you’re struggling to get any sense of product-market fit, start talking to users and run experiments to test new directions. ![](https://www.productftw.com/content/images/2024/02/mirrormeme2.jpeg) Oops **The team vibe–**Evaluate the effectiveness of your team dynamics through these points: - Cross-Functional Collaboration: Are you and your team (engineering, design, sales, marketing, CEO) working together seamlessly? Early-stage demands quick decisions and a lack of silos–identify roadblocks. - Aligned Goals: Does everyone understand the immediate product goals and their role in achieving them? Are team goals connected to broader company objectives? Misalignment wastes time and resources. - Communication Impact: Open, honest communication is vital. Do you receive consistent updates, are opinions respected, and is feedback constructive? Communication breakdowns affect morale and performance. It’s essential to hold regular retrospectives (even during intense periods) to discuss wins and areas for refinement and celebrate collective accomplishment. Retrospectives build trust, highlight processes that might need streamlining, and keep everyone motivated. **Process or pain-in-the-ass–**The processes you rolled out should make your life easier, not harder. Assess them by: - Speed of Iteration: Can you release features and updates at a reasonable pace? If everything feels sluggish, you need to investigate why. - Bottlenecks & Blockers: Can you quickly pinpoint where work gets stuck? Look beyond obvious tech bottlenecks–unclear ownership, poor handoffs, bureaucratic approvals, or outdated information in your documentation can cause delays, too. - Process vs. People Problem: Does everyone follow processes diligently? If people constantly bypass systems, even simple ones, that points to communication or buy-in issues, not just faulty processes. - Organized Chaos: Are people truly using your documentation system? Can everyone find what they need (specs, decisions, guides), or has it become another place where knowledge goes to die? If the docs aren’t cutting it, that’s fixable–but first, figure out why it’s being ignored. Use your team retrospective to uncover deep-rooted process problems, and be open to adjusting processes. Early-stage requires adaptation, so what worked three months ago probably needs adjusting now. Remember, there are no failures at this stage, only lessons. Now’s the time to put everything you learned over the past six months and make bold, well-informed choices that empower your whole team to learn, build, ship, measure, and repeat. The fun really starts once you get these things humming! # One year in At this point, the initial chaos has settled (slightly…maybe). You have a good handle on the product, the market, and your team’s operations. This isn’t a time to coast, but to reflect on everything achieved and the hurdles overcome, and use this knowledge to refine and strengthen your strategy going forward. As you reflect on the past year in an effort to plan for the next, here are the key points to address: **Team Evolution–**If things are going well, you will hire more people to propel the business forward. Roles will change, and new people dynamics will shake up what’s been working. Some things to keep in mind: - The newbie factor: New hires mean new voices. Is that initial team magic starting to fizzle? Be upfront–a shake-up isn’t bad as long as the work gets done. - When processes break: Were those smooth early systems built for three people, not your growing crew? Be ruthless in spotting where bottlenecks ruin everyone’s day. - Influence struggle: Suddenly feeling outvoted when it comes to product vision? This means rethinking how you get and maintain team buy-in on where things are headed. Once again, retros are a fantastic way to reflect on the team dynamics. They feel weird, especially with a new cast of characters, but if you do them right, the team will complain when you don’t have one! **Product-Market Fit–**Make sure your roadmap reflects what your users and data tell you. Consider: - User feedback loop: Did you build feedback channels people actually use, or are there only crickets and the occasional support ticket? Support tickets tell you things are broken, not what needs building. You have to talk to your customers to learn about the good, the bad, and the ugly. - Market monitoring: What’s trending in your industry? Has AI made your product obsolete or more compelling than ever before? What are your competitors doing? Keeping a pulse on the broader market will give you an edge and ensure you’re not building in a vacuum. - Measure what matters: It’s tempting to track any and everything in the hopes it might be valuable one day. Save yourself a lot of time and effort and track only the metrics that move the business forward. If you’re having trouble prioritizing what metrics are most important, try Gibson Biddle’s [GEM framework](https://gibsonbiddle.medium.com/9-the-gem-model-65c89face5de?ref=productftw.com). **Your fit at the company–**Startups are hard. Most don’t work out. After the first-year trenches, do you see yourself thriving here or just surviving until something better appears? Consider: - Product Love: Is the problem you solve still genuinely compelling? Maybe early passion blinded you to realities. It’s okay for even great products to become a slog as business and customer needs evolve. - Team Trust: Do you work with brilliant people who uplift you or alongside egos and folks coasting on their past? Be brutally honest here – team energy dictates how tough those future roadblocks feel. - Leadership Alignment: Are your values reflected in the CEO’s decisions, even the hard ones? If not, every roadmap success will feel tainted. This mismatch only gets worse, not better, over time. - Your Growth Curve: Look back at Day 1 vs. now. Are you still rapidly learning new things, or has it become routine? If every challenge feels like déjà vu, you may have outgrown what the company offers. - Burnout vs. Bad Times: Startups have cycles. Are you down because of temporary struggles the company will likely overcome, or is that sinking feeling permanent? Don’t confuse tough phases with a fundamentally mismatched job. It’s crucial to distinguish burnout from a bad fit. Burned-out PMs with the right opportunity can soar again. If there’s a mismatch, even at a thriving company, you’ll never reach your full potential. Year One gives you enough data to know the difference. # PM life is tough By this point, that fire hydrant is still erupting at full pressure, but instead of just gulping down whatever’s thrown your way, you’re directing the flow where it’s needed most. Keep up that pressure; keep pushing, keep learning, and hey, maybe a year from now, you’ll even feel organized. Or, you know...mostly organized. It’s also important to know that the early-stage PM experience can feel isolating at times. Remember, you’re not alone! There’s a whole community of product builders facing similar challenges and learning as they go. Seek out resources, talk to other PMs, leave us a note or a comment, and know that every lesson–hard-won or not–makes you a better product leader. Year two, here we come! --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Being the First Product Manager - ProductFTW #4 URL: https://www.productftw.com/productftw-4-being-the-first-product-manager/ Last updated: 2026-05-22T02:07:20.000Z You’ve gone and done it—jumped headfirst into the chaos of a startup, snagging the role of the first product manager. In this world, order is a myth, the process is a joke, and literally everyone is winging it. It’s a beautiful mess, and learning is less a choice and more a survival instinct. As *the* product manager, your job is to turn this beautiful mess into a well-oiled machine that can pump out products and features that are so good that customers are ripping it out of your hands. Easy-peasy right? *If only.* ![](https://www.productftw.com/content/images/2024/02/thisisfine-1-1.jpeg) Where can I buy this chair? I’ve had the privilege of being PM #1 a couple of times now, most recently at an early-stage startup called Perigon, where I’m about to hit my first anniversary. I thought it would be a good time to reflect on what I’ve learned and share what to expect in your first year as the inaugural PM in the hopes that I can save someone time and effort, preventing the headaches that I went through. And to be clear, this is just my take– there is no data, no studies, simply the lived experience from someone still in the thick of it. *This will be a two-part series; this first half will focus on the first week and proceeding month as the first PM. Part two will be focused on the next 6-12 months.* ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. # Week 1 ![](https://www.productftw.com/content/images/2024/02/Artwork-4.png) PMs stay hydrated. Get ready to drink from the fire hydrant. Your first week will be overwhelming, messy, and stressful. Early-stage startups will not have a pleasant, informative onboarding experience like you’d expect from bigger companies–and if they do, you should question whether they have their priorities in the right place! Your sole responsibility this first week is to learn as much as possible. The only way you’re going to do that is by staying organized. Write *everything* down. Record it, have AI transcribe it, whatever. The things you learn this week will be foundational to everything you do going forward. Chances are, no one has documented anything you’re going to learn this week anyway, so you’re going to be the person who’s going to do that (and every week after that!). This is not an exhaustive list, but try to focus your first week on learning about the most important aspects of the business. This includes: - The company mission and vision. You should have some sense of the mission and vision since that’s hopefully what convinced you to join a startup in the first place, but try to spend time with the CEO and founders to dig into this more so you can start off with the right north star. This is also the opportunity to better understand the overall business strategy. - The team. It takes a village–meet your team and get to know them, what they do, their responsibilities, and how you can help them as the first PM. They will be instrumental in teaching you about the current state of the business. - The customers. You can’t have a product unless you’re solving a problem for someone. Who are your current customers? What problem are you solving for them? If you don’t have customers yet, what does your ideal customer look like, and why would they use your product? - The product. The thing you will soon be the expert on and responsible for. What is the main value prop? What are the features? Are there current usage metrics, or is there customer feedback? Is there a roadmap, and what’s on it? - The tech. How does the product work under the hood? What’s the tech stack, and what are the external dependencies? Is there technical documentation (that’s a joke–of course there isn’t)? How is work currently prioritized and managed? - The go-to-market. How do people learn about the product? What marketing or advertising is being done? - Current goals. Are there any KPIs that the business is working towards? What are the teams focused on now? Are there any new features or product launches on the horizon? That’s a lot to learn in just a few days! Don’t worry, just stay organized. It will get more accessible, and things will start to make sense soon. If you’ve done this right, by the end of the week, you should be able to create a [Lean Business Canvas](https://miro.com/blog/lean-canvas/?ref=productftw.com)\- validate your understanding of the business with the CEO, then go home and have a beer. 🤝 ****A note on working with the CEO** The founder/CEO is the original product manager. With you now in the hot seat as the actual product manager, you will need to form a close relationship with them as you help bring their bigger vision to life. This relationship is more than just taking orders; it's about engaging in a constructive partnership where you blend the CEO's strategic foresight with the actual realities of product development. You will ideate, debate, analyze, and measure the success of the product together, and it's ok to push back, offer alternative viewpoints, and give constructive feedback as you build a partnership together. But, at the end of the day, the CEO is your boss. Sometimes, you will have to disagree and commit to a feature or decision you don’t believe in, and that's ok- changes are cheap at this stage of the company. Use data and facts to bolster your case when you are at odds, and more often than not, things will work themselves out. # Month 1 ![](https://www.productftw.com/content/images/2024/02/chainsaws.jpeg) Safety first. First week down, and you’re still breathing–score! Your first week was ideally a crash course in the business, and you soaked it up like a sponge. The odds are pretty high that everything felt messy and unorganized (except you–you took meticulous notes, right?), so this next month will be focused on fleshing out the product strategy and creating structure through process. Your priorities should generally align with the following: - Creating the product strategy. Unless the CEO has already created a product strategy (unlikely), you will need to create one. Based on your learnings from Week 1, take a stab at creating a short to medium-term product strategy document that aligns with the company goals (Don’t have company goals? Get with the CEO and create them). This product strategy doesn’t need to be long and complicated right now; just define your target customer, what products or features you will create to solve their problems, and what goals you have for the near to medium term. Like the Lean Business Canvas, validate the product strategy with the CEO, then share it broadly with the company. - Planning the Roadmap. With the product strategy in hand, you can get tactical and start figuring out what to build. All you need to do right now is stack rank the proposed features- scope and timing don’t matter yet. - Create structure through process. Process can be a scary word, especially at a fast-moving startup, but it doesn’t need to be. Process right now is simply defining how to communicate within your team. If you can do these 3 things, you’ll be in good shape. 1. Align communication patterns with your team. Should you use Slack or Discord? Google meet or zoom? This is the first place to start so that you can collaborate and coordinate on everything else. 2. Embrace an internal company documentation tool, like Notion. This is where everyone should now keep documentation like the product strategy, roadmap, requirement docs, tech specs, and more. 3. Figure out your SDLC. Work with your design and engineering peers to figure out how things go from idea to requirements to code to a product in the customer’s hands, and then use something like Linear for task tracking. Keep this simple and lightweight. - Lead by example. Introducing the product strategy, a roadmap, and a process is more than enough to ruffle a few feathers. You must continue to be the most organized person on the team, creating incredible documentation and artifacts, championing any new systems you introduce, and facilitating their adoption. You will have to remind people to adhere to the process constantly. Just don’t be an asshole about it–show them what good looks like by being great. With these foundations in place, you’re turning the startup mess into a clear game plan, ready to kick things into high gear and make stuff happen over the next few months. Next week, tune in for part 2, where we’ll turn our attention to the next 6-12 months. 📣 Part two is now live. Click [here](https://www.productftw.com/productftw-5-being-the-first-product-manager-part-ii/) to continue reading. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Startups vs. Big Companies - ProductFTW #3 URL: https://www.productftw.com/productftw-3-startups-vs-big-companies/ Last updated: 2026-05-10T23:39:40.000Z We've observed that many product management newsletters and blogs predominantly feature interviews with product managers and leaders from large corporations such as Google, Facebook, and LinkedIn. The term "startups" is often loosely applied to any tech company. However, we define a startup as an early-stage, high-growth, venture-backed company for this discussion. ![people doing office works](https://images.unsplash.com/photo-1504384308090-c894fdcc538d?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDQ2fHxzdGFydHVwfGVufDB8fHx8MTcwNjU4MzY5NXww&ixlib=rb-4.0.3&q=80&w=2000) Photo by [Alex Kotliarskyi](https://unsplash.com/@frantic?ref=productftw.com) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) The size and stage of a company significantly influence the expectations and demands placed on a product manager. Most of my experience is with early-stage companies. However, I gained insight into large company product management during my tenure at AT&T Interactive (yellowpages.com) from 2009 to 2012. Many startups, typically with a single product, only require complex cross-team coordination once they experience substantial growth. While teams may manage different aspects of the product, such as a web front end, a mobile app, and a backend, these teams often work in unison towards a singular product experience for the end user. Resources such as product design and development operations are frequently shared in smaller companies. In contrast, larger companies often have more extensive individual product teams, each with dedicated product design, user research, and complete engineering teams. These larger entities also face the challenge of coordinating multiple products, necessitating more service teams. While at AT&T Interactive, yellowpages.com was a top-25 site in the United States and the leading local search site before the rise of Yelp or Google Local. We generated over $1 billion in annual revenue and employed more than 400 engineers. Our structure included separate product teams for web, mobile, advertiser systems, publishing systems, and various services like login, search, analytics, etc. In many larger organizations, there are typically two types of product managers. Some product managers work directly with a software development team, engaging in standard software development lifecycle (SDLC) processes, such as agile ceremonies and standups. These individuals are technical product managers. Others, known as business product managers, need dedicated engineering teams and focus on implementing product enhancements across all products or with outsourced teams. My team, responsible for managing $700 million in revenue, fell into the latter category. We oversaw our advertising listings and marketing services. To launch a new ad product, we had to define the product, develop marketing and channel sales strategies, and implement them across services, ad platforms, publisher networks, and all consumer front-end teams, all without dedicated engineering resources. In contrast, a small startup with 10-20 employees might have just one product manager overseeing all products. In such companies, the PM is often tasked with writing requirements and managing projects, whereas in larger companies, these roles are typically filled by dedicated project managers or scrum masters. In summary, a key distinction between the experiences of product managers in large versus small companies lies in the level of support and complexity they manage. Product managers in small companies need more extensive support teams found in larger companies but also need more complexity in coordination. In a small company, the CEO, often the founder and visionary behind the company and its products, typically drives the roadmap and vision, leaving the product manager to focus more on execution. In contrast, in a larger company, the CEO acts more as a general manager, with the Chief Product Officer or VP of Product responsible for defining and executing the vision. As a result, the skill sets required vary significantly between companies of different sizes. ### The Tire Swing Cartoon - ProductFTW #2 URL: https://www.productftw.com/productftw-2-the-tire-swing-cartoon/ Last updated: 2026-05-22T02:26:13.000Z *Originally published January 25, 2024\. Revised May 2026 with origin history, variants, and frequently asked questions.* ### What the Customer Really Needed ![A ten panel comic showing various stages of the product development lifecycle.](https://www.productftw.com/content/images/2024/01/tree_swing_development_requirements-1.jpg) "What the customer really needed" ## Where the tire-swing cartoon came from The image traces to the [University of London Computing Centre's *ULCC News* Newsletter #53](https://www.computinghistory.org.uk/det/4523/ULCC-News-March-1973-Newsletter-53/?ref=productftw.com), published in March 1973\. The cartoon appeared as anonymous corporate humor about how software requirements drift through stakeholders. From that single newsletter it spread quickly through IBM training materials, system-analysis textbooks, and consulting decks throughout the 1970s and 80s–no individual author is credited, just "ULCC News." ![Original ULCC News 1973 tree swing cartoon showing how project managers, analysts, and developers each interpret customer requirements differently](https://www.productftw.com/content/images/2026/05/product-75321.jpg) The O.G. Tire Swing Cartoon. The original cartoon from ULCC News Newsletter 53, March 1973\. Image via the Centre for Computing History. What gave the cartoon staying power is that every panel is true. Project managers, engineers, business analysts, and customers each describe the same product and produce mutually incompatible mental models. By the 1990s, the image was a fixture in training; by the early 2000s, it had been adopted by the agile community; today, it's standard issue in product-management writing. ## The cartoon you've seen vs. the ones you haven't Most people know the seven-panel "what the customer wanted vs. what was delivered" version that's been screenshotted into thousands of slide decks. The cartoon has several other variants worth knowing: - **The classic IT version** : 7 panels covering customer description, project leader, analyst, programmer, consultant, operations, billing, what was installed, support, and what the customer needed. - **The agile version:** 4 panels, emphasizing that early customer involvement would have caught the misalignment. - **The lean/MVP version:** 3 panels: what was asked for, what was actually needed, and what shipped first. - **The "everything went wrong" version:** adds a final panel where the tree has been chopped down and the customer is still unhappy. Each variant makes a different argument about *why* the original misalignment happens. The IT version blames role-based silos. The agile version blames waterfall sequencing. The lean version blames over-specification. The pessimist's version blames the customer. Want practical product-management writing every Thursday? Get ProductFTW in your inbox — real advice from operators who'veshipped, with a fintech focus. Subscribe → [Subscribe ](#/portal/signup) ## My First Cartoon Swing Experience I distinctly recall the first time I saw it. In 2006, I joined Green Dot Corporation as a Product Manager. I was employee number 65 or so. The company had raised its Series B with backing from Sequoia Capital and was well on its way to a billion-dollar IPO in 2010\. When I arrived at Green Dot, it didn’t run Agile or another modern software development methodology (although we did try (and fail) to convert to Agile during my three years there). Product Management was a business function that reported up to the President and head of revenue. Our technology team included business analysts who took our Product Requirements Documents (PRDs) and converted them into Technical Requirements Documents (TRDs) and, in turn, created tickets for engineering. We had a very messy yet traditional Software Development Lifecycle (SDLC). It was waterfall, yet we deployed software every week when I arrived. There was a lot of “1.1.1.1 The password shall be eight characters.” I was introduced to folks in the Technology team early on and met Kim Kelly, then Director of Business Analysis. She had this cartoon pinned up on her cubicle wall. At the time, as a fresh PM and only 23 years old, I didn’t truly get it. What everyone loves about this cartoon is that it pokes fun at just about everyone in the organization. Don’t get me wrong, it is funny. I also see a lot of folks on the internet saying effectively, “What the customer wanted” is the title. From a product manager’s standpoint, both of these miss the point. I’ve used a variation of this version to make a point in every company where I’ve been a CEO or Chief Product Officer: The role of the product manager is **to understand “what the customer really needs.”** ![](https://lh7-us.googleusercontent.com/xyBibTdl48fmBstIOXMXno9tl-0jeD5N8g-LOpdBXHFwZkCJiMKSVKmIOSH7wzHEn7fb71ajmOr7kgZMX9ov8TMN1eUX5yRLLWbay-ajOs-QxE2q57FhwBOFtCPNn56c6NpIXPBbgrcFr83MmKPISTw) There is a lot of valuable humor in the rest of the cartoon that goes into how to improve the SDLC. However, the start of building a successful product is to know what it is you need to build in the first place, and that starts with knowing what the customer **needs,** not what the customer **wants.** I often use an over-the-top example for this with the Apple iPhone. If you had asked the majority of cell phone customers in the early 2000s what they wanted from a cell phone, you might have heard a few things: - Smaller - Better audio quality - Longer battery life A few of us were trying to figure out how to combine our Palm Pilots with our cell phones, and business nerds everywhere were clamoring for the Blackberry. I don’t think any user survey or customer inquiry would have resulted in: “I need a touchscreen supercomputer in my pocket that is connected to the internet so that I can check my email, get directions, surf the internet, and maybe sometimes make phone calls.” What the iPhone showed us is that this is what customers really needed. The iPhone and other touchscreen smartphones have destroyed the competition by answering so many needs and use cases that most folks would give up a lot of other devices before their smartphone. I use the tire swing comic to make a point about what product managers are trying to accomplish: understanding user behaviors and needs. A good product manager isn’t an order taker. Sometimes, a simple request is all that’s needed, and a task is managed through the SDLC. A good product manager needs to understand the **why** and the **value** of that task so that they can prioritize and enhance it. Having empathy for your users, their challenges, and their needs is core to building successful products. If you can put yourself in your users' shoes as a PM, you have a real chance of creating something they will appreciate. Many PMs find it easy when building a product for themselves, but the best PMs know how to do this even when the product isn't within their personal experience. The idea of understanding what your customer really needs is deeply embedded in the construct of user stories: As a **user,** I want software to do a **task** so that I can **achieve a goal.** Achieving a goal is about a need, not simply understanding a description. With no disrespect intended, people usually don’t articulate the underlying need very well, and it is up to PMs to help unearth that need. ## Sign up for ProductFTW Subscribe Email sent! Check your inbox to complete your signup. A unique newsletter about product management in technology startups. Advice about how to get shit done because, in the end, product management is about shipping valuable software. Enjoy a laugh, tape this cartoon to your wall, and remember to focus on user needs–not wants. ## Common questions about the tree-swing cartoon **Who created the tire swing cartoon?** No single creator. The cartoon emerged from anonymous corporate humor in the early 1970s and was passed around via Xerox copies, internal newsletters, and overhead transparencies for decades before the internet. Modern variants are adapted by individual designers, but the original sequence has no attributed author. **What does the tree swing meme mean?** It illustrates how the same product specification produces wildly different interpretations across stakeholders. A customer describes what they want, the project manager hears something different, the analyst documents something different again, and engineering builds yet another thing. The gap between "what the customer needed" and "what was installed" is the cost of communication failure across roles. **Where did the tire swing cartoon come from?** It first appeared in [University of London Computing Centre *ULCC News* Newsletter 53](https://www.computinghistory.org.uk/det/4523/ULCC-News-March-1973-Newsletter-53/?ref=productftw.com), published March 1973\. From there it spread through IBM training and system-analysis textbooks before being adopted by the project management and later agile communities. **Why is the tree swing cartoon still relevant?** Because the underlying failure mode hasn't changed. Modern product teams still produce specs that look reasonable on paper but render incompatibly across functions. The cartoon is a useful diagnostic: if your team can look at it and not see your last project, you're either exceptionally aligned or not looking carefully. **What's the right fix for the tree-swing problem?** Direct customer-to-engineer contact, working in short iterations with feedback loops, and shared definitions of "done" across roles. The cartoon is making the case for collaborative requirements work: PRDs written *with* engineering, not handed to them. See [Mastering the Art of Requirements](https://www.productftw.com/mastering-the-art-of-requirements-prds-that-actually-work/) for the practical playbook. --- *Part of the* [*Product Requirements Field Guide*](https://www.productftw.com/product-requirements/) *— ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.* ### What is a Product Manager? - ProductFTW #1 URL: https://www.productftw.com/productftw-1-what-is-a-product-manager/ Last updated: 2026-05-22T02:07:19.000Z Product management has been a buzzword and a hot career path for nearly two decades. Product managers are the new rockstars made famous by software juggernauts like Google and Facebook, wielding more influence than ever and commanding eye-popping paychecks on par with elite software engineers. But where it’s easy to see the output of an engineer (the code), a designer (the UI), a marketer (the ads), or just about any other role, it’s not as easy to see what the output of a product manager is, leading to an oft-asked question: > **What the hell is a product manager in the first place?** Let’s start with some definitions. ![Meme photo from Office Space the movie, "What would you say you do here...."](https://lh7-us.googleusercontent.com/-dPvIsFS1PMi5cTkyFA0mSFe97MqSkqvCtqpXc0Ouf0GeeYBptbbv9kqEiUvnvo3Cfp47fM1Cp-epp5rPMZfpCyk7bjqwkp1615Jnj0USJnyookPgM08-bq1NvpsDbwSOXLvCbzwmC2FbI1FU_rx5R8) This scene is about a product manager-type, for real. # What’s a product? There are plenty of lengthy essays and countless attempts across the web to define what a product is philosophically, and all of those are mostly bullshit, so we can keep this part short. ****A product is something that’s created to provide value to someone.** *That’s* *it.* More discretely, a *product* can be something physical (like a laptop or a muffin), a service (tax preparation), an experience (a heavy metal concert), and more. The *value* people derive from a product is also far-reaching and can include saving time, having fun, reducing risks, improving performance, and beyond. ![Table with Product on left, Value on right. Three examples: muffin>nutrition, laptop>productivity, concert>fun!](https://www.productftw.com/content/images/2024/01/Untitled_Artwork-2.png) The value of products From here on, we’ll mainly talk about software-based products. Software products are typically a collection of individual features that, as a whole, form a product that is offered to users through a website or app. As an oversimplified example, let’s look at a product I helped build a few years back called the TPG App. The value we aimed to create was to help people maximize all their bank, airline, and hotel points to travel the world for free. We had three features: - Feature 1: Learn–Read TPG content in a streamlined, mobile format to learn about airline, hotel, and bank loyalty programs - Feature 2: Earn–Connect your credit card and loyalty accounts to learn how to maximize your spending to earn the most points - Feature 3: Burn–Search for flights and hotels that you can redeem with your points ![Three screenshots of the TPG App in Beta, home screen, cards screen, points screen.](https://www.productftw.com/content/images/2024/01/TPG-App-Screenshot.webp) Some screenshots of the TPG App in Beta By combining these three features, we created a product that helped people learn how to travel the world using lucrative loyalty programs, track all their points in one place, and then determine how to maximize them. # What’s product management? Just as defining a product is straightforward, the concept of product management, often shrouded in jargon and complex theories, is fundamentally simple, too. ****Product management is identifying a need, creating a solution to meet that need (e.g., the product), and continuously refining it based on feedback.** The act of product management has been around just about forever and applies to nearly everything we interact with every day. From the ancient potter who crafted vessels for their village to the hat maker of the 1920s designing stylish headwear to the modern-day SaaS shop building accounting software, product management is, and always will be, about creating solutions to problems. It’s both the art and science of guiding a product from the initial idea sparked in someone’s mind through the maze of development and user feedback to its final form as a tool or service that people rely on. ![Cycle with Problem > Solution > Feedback > back to Problem](https://www.productftw.com/content/images/2024/01/Untitled_Artwork-3.png) It's a never-ending cycle Product management’s most critical and challenging aspect involves understanding what users need (even when they might not know it). Putting yourself in the user’s shoes, envisioning a product that solves their problem, and then meticulously refining it based on their feedback is how truly meaningful products are created. It’s a continuous dance of feedback and iteration, ensuring each feature works well and contributes to the product’s overall value. To illustrate this a bit, early in testing the TPG App, we learned that many people had anxiety when booking a flight since pricing can change by the minute. “When do I use my points vs paying out of pocket with cash? I want to get the biggest bang for my buck!” was a common refrain. With this feedback, we introduced a simple but intuitive feature that assigned an actual dollar value to a user’s reward points, making it easy to understand the tradeoff of cash vs points. We made our users happy, increased engagement, and ultimately made our product more valuable. ![](https://www.productftw.com/content/images/2024/01/IMG-1019.png) Cash or points? A simple feature with a lot of value. This is the essence of product management–it’s not just about building a product; it’s about evolving it to remain relevant and valuable in an ever-changing world. # What’s a product manager? Building on our understanding of what a product is and the fundamentals of product management, we can come full circle and finally answer our initial question— what exactly is a product manager (PM)? This role isn’t just another cog in the machine; it’s the operation’s critical, pulsing heart. The product manager embodies the principles we’ve laid out: creating value through products and refining them based on feedback. ****A product manager leads a product from idea to market and beyond, balancing user needs with business goals.** In principle, the product manager’s goal hasn’t changed since antiquity. In reality, the modern-day product manager has much more on their plate than the potter or hat maker. Talking to users, understanding their needs, and finding ways to solve their problems are just one part of the puzzle. PMs must also prioritize the most crucial products or features, validate it’s possible to build them within a given timeframe or budget, ensure the product aligns with the overarching business goals, and have the buy-in from internal stakeholders. They are then responsible for actually driving the product through development to launch. *In future posts, we’ll dig into the Product Development Lifecycle and discuss how products go from idea to market.* A simple feature, like the points *vs.* cash comparison in the TPG App, can be complex to build and launch. ![Comic of the TPG app.](https://lh7-us.googleusercontent.com/hCGHgV7DSgQ1MBM3_m34OzJFWucLt5U81UH4-qc5g11JmaC332VVImGD9oxsz0no1lcCX7LZzjqn-z3X6lDQoZ0YcAD9yOtviRYy1dhOfaVa9GXqyFMdbnSX3l5QjUGReiWF9_ox-XHwQeAqGh8K57w) A day in the life as PM of the TPG App Think of a PM as an orchestra conductor; PMs aren’t directly playing an instrument but are responsible for getting everyone in tune, playing the same song at the right tempo, to create beautiful music. Put another way, product managers ensure that stakeholders (marketing, sales, legal, etc), engineering, design, and all other relevant parties are aligned and working on the same customer problem with the same intensity to deliver the most value to users. So when we talk about the product manager’s output, it’s in the name itself: the product. A product manager is a catalyst in product development – turning ideas into reality and ensuring that reality evolves with the ever-changing needs of users and the business. They don’t just manage products; they lead them through their lifecycle, ensuring they grow, adapt, and thrive in a competitive landscape. The job is hard, the hours are long, and when done right, rewarding as hell. --- *Part of the* [*Product Management Leadership & Career Guide*](https://www.productftw.com/product-leadership/) *— ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.* ### Introduction to ProductFTW - ProductFTW #0 URL: https://www.productftw.com/productftw-0-introduction-to-productftw/ Last updated: 2026-05-10T23:39:36.000Z Welcome to ProductFTW: a unique newsletter about product management in technology startups. ProductFTW is exclusively advice about how to get shit done because, in the end, product management is about shipping valuable software. Everything else is noise. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. # Some Background In 2020, I started [CardsFTW](https://www.cardsftw.com/?ref=productftw.com), a newsletter on all things related to payment cards. My friend and colleague Peter had told me to stop sharing my thoughts on an internal Slack channel and start sharing with the world. I didn’t think much would come of it, but today, it has more than 2,000 subscribers and has led to meaningful conversations, relationships, and business deals. When I started Totavi in the spring of 2023, my goal was to build a sustainable and affordable consulting business, primarily for startups, that would help them conquer their product challenges. While the majority of our business is in fintech, it isn’t all we do–with a substantial portion of our revenue coming from non-fintech products and executive coaching. Our clients often ask us for product-related advice, but offering quick references is challenging because they don’t align with our viewpoint or are unrelatable as a startup. We noticed there is a content gap. ## Our Goals for ProductFTW We have an awesome team of voices that will be contributing to ProductFTW. Ellen, Zach, Jessica, and I first worked together as a team at Bankrate. I was the Chief Product Officer, and this trio represented the best three product managers. Since then, we have been fortunate to reunite at Apto (all four of us) and Totavi (sorry, no Zach). Now, we are reuniting to put this together with much more experience than when we met almost a decade ago. We will write about realistic approaches to products that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide yet. Those are great environments and have their challenges. We will write about our experiences as founders, the first (or only) product people at a company. We’ll share our favorite stories. We’ll talk about building a product org or rebooting an organization. We’ll also share our failures. It should be fun(ny). Thanks for subscribing!