Product Playbooks
Decisions that shape the product itself — what to build next, when to say no, and how founders used real feedback to steer the roadmap without losing focus.
277 tactics · page 9 of 10
“you can use AI to scan the app store every day look for copycat apps we've built stuff at Fabulous to do this we look at the app store every day we're looking at stuff that's rising virally we're scanning it we're looking at the ads that they run and so we have defense mechanisms for this.”
Use AI to scan the App Store daily for copycats — the defensive use case is as powerful as the offensive one
Seufert flips the copycat conversation: AI is a defensive weapon, not just an offensive one. At Fabulous, he built automated App Store scanning to detect rising copies and analyze their ads in real time. The lesson from years of creative copying is that it accelerates the need for a repeatable creative production process — companies that continuously generate winning creatives pull away while copycats eat crumbs.
“the AI takes over everything bulls are underestimating the productization that takes place that all the people at Straa who've been building this product over years and have that knowledge and have new features they're continuing to add on in a weekly monthly cadence you just you don't get that.”
AI replacing apps requires productizing the use case — incumbents have a years-long runway to do it first
Seufert argues that productization is the underestimated moat against AI replacement. Running coaching via ChatGPT is technically possible, but it lacks the memory, training log, social layer, and weekly cadence of new features that Strava delivers. Replicating all of that in an LLM interface would require years of focused product work — giving incumbents a durable runway to integrate AI into their own products first.
“instead of asking people to rank things on a scale what you do is you give them some list of attributes categories and you say out of this list what's the most important to you and what's the least important to you and then you calculate tally all of that up”
Use MaxDiff instead of 1-5 ranking to actually prioritize features
Likert-scale feature rankings bunch every option at 'kinda important' and tell you nothing. Use MaxDiff instead: force respondents to pick the MOST important and LEAST important from a list, then score each item as most-count minus least-count. One founder ran this and found his planned roadmap scored near zero while a harder, unsexy feature scored highest.
“that's how I avoid building unwanted features I have tons of feedback about potential features for p fast and what made it successful is because I built it for myself and if I listen to all those feedbacks I'm going to build a very complex boiler plate and I do not do that instead I use it for myself”
Dogfood as feature filter — ignore the wishlist, eat your own work
Marc gets endless feature requests for ShipFast and rejects almost all of them. The filter: only features he hits while shipping his own products get added back. Customer wishlists bloat boilerplates into Frankenstein products — personal use is the discipline that keeps them lean.
“you would never hire a uh human employee and then not give them a brief on the type of tasks that you want to do right you wouldn't hire an agency and say um you you make up the marketing campaign I don't care you know you would say okay here's the brief here's the kind of thing I'm looking for”
Prompt principles are just manager onboarding: brief, format, examples
The same instincts that make a good manager make a good prompter: give clear direction, specify the format (JSON, bullets, paragraph count), supply examples of past good work, inject knowledge the model doesn't have, and state opinions the average person wouldn't. These principles survived the GPT-3 to GPT-4 jump and will likely outlive GPT-5.
“I don't want it to say yes to something that is a no but it's fine for me to for it to say no to something that that might be a yes I don't care about the the false negatives that those are acceptable because I have like 20,000 podcast episodes coming in in a day”
Pick the asymmetric error tolerance before tuning the prompt
When the input firehose is big, optimize the prompt for precision, not recall. A wrong 'yes' burns user trust on every notification; a missed 'yes' is invisible. Encode that asymmetry directly into the eval scoring before tuning — penalize false positives ~10x more than false negatives, then chase that number. Arvid hit 99.8% on a podcast-classifier doing exactly this.
“I would use like one two three like extremely important somewhat important and not really important hopefully it's a pyramid like a few ones a little bit more twos and a lot of trees and then okay everything that's a one I want to display right away and then the twos are maybe behind the show more”
Sort every UI element into 1s, 2s, and 3s before designing
Founders default to 'everything is important' because every datum has a purpose to them. The fix: list every element a page could show, then tag each as 1 (critical, displayed immediately), 2 (collapsible / show more), 3 (buried in settings). If almost everything ends up as a 1, run the exercise again on just the 1s.
“you can let your users do it as well the card sorting exercise you make all the sticky notes within a Miro or FigJam then you let them sort it put it into groups and let them decide how would you group this”
Let customers card-sort your features instead of guessing IA
For founders who can't trust their own priority intuition, run a lightweight card-sort in Miro or FigJam: one sticky per feature/info element, then let users cluster them however they want. The clusters become section headers, nav labels, and the natural order of pricing or feature pages.
“what's really interesting about tweet Hunter and tapio is that it has it's able to provide a lot of value with a lot of different uh small tools which are are not too much dependence on the one from each other so it creates less um Tech complexity and so way less BS”
AI products win with many loosely-coupled tools, not one monolith
Tapio and Tweet Hunter grew from ~$2M to ~$6-7M ARR by shipping many loosely-coupled mini-tools instead of cramming features into one monolith. Less tech complexity, fewer bugs, more surface area for value. Bolt-on standalone utilities fail cheap and succeed huge — they don't break core stability when they flop.
“the first couple times we tried it it was like amazing the problem is over time there's just enough like hallucinations and things that were wrong that I ended up not being able to trust it so I basically had to go and recheck the work every single time which more or less reduced the value of it back to zero”
LLM workflows need a reliability filter before they create leverage
Most AI-augmented internal tools feel magical for the first few runs, then hallucinate enough that you re-check every output — eroding all the leverage. Real value comes from the small subset of tasks that survive a reliability filter and graduate into trusted automation. Run new LLM workflows in shadow mode for weeks; promote only the ones where you stop double-checking.
“a lot of the artistic part of audio only is actually being washed away because everyone wants to just grow grow grow and they're going to video I'm actually curious about how do we take this audio first experience and make a video out of it make an amazing audio product and then video will come second”
Audio-first beats video-first — production depth video chasing can't replicate
Most podcasters are migrating to YouTube-style conversational shows because clips distribute easily, but that washes away audio's depth. The shows that build the deepest engagement are audio-first because the format puts the host inside the listener's head. Optimize for ear-only consumption (production quality, narration, sound design) first; treat video as downstream.
“there are places in the world where your 50 megabyte website that includes like big images that shouldn't be as big and video content that shouldn't be there might actually cause people not to even go there because they see it and they immediately stop because 50 megabytes of download could be like a significant portion of what they have in their budget for the month”
Treat page weight as financial accessibility
A bloated 50MB site doesn't just hurt Core Web Vitals — it locks out entire countries where loading one page eats a real chunk of a monthly mobile data cap. Strip the marketing site to minimal images, no autoplay video, and lazy-loaded assets. Page weight is a pricing decision in disguise; the buyers PPP pricing was meant to attract bounce before they ever see the offer.
“a friend of mine that owns a printing company uh wants to update his Tech right... I had Max and Sparky's uh Galactic Dre uh on a back burner for a little while um and I was like hey man I got this book right and used AI to do some help... I got to learn how this process works by building something for me at the same time”
Build a side project to learn another business
When you're building software for an industry you don't know, ship a real product through that industry's pipeline yourself before writing code. Andrew wrote and printed a Ruby kids' book to learn his friend's printing business end-to-end — ISBN, copyright, margins, ebook vs print. Building the thing the customer builds teaches you more than any discovery call.
“I would not say as a loss leader for sure... I will say that we will always index toward trying to reach more users with the devices and bring more users in the ecosystem versus trying to maximize the the margins of the devices”
Treat hardware as ecosystem glue, not loss-leader or profit center
When you have both software and hardware, the temptation is to optimize each P&L separately. Don't. Price hardware to maximize ecosystem entry while staying break-even or modestly profitable on the device itself. Hardware buyers retain better on the SaaS, extend the usage lifecycle (Tile in a backpack before a kid has a phone; Pet GPS after the kids leave for college), and lift LTV through both channels.
“I think very few companies have success developing a second app you no matter the size of your first... Even Duolingo... they launched I think it was either chess or math as a separate app and then they had to bring it back into the main app”
Expand the app — don't spin off a second one
Resist the "let's spin out a sister app" instinct. Even Duolingo failed at it and pulled the standalone back into the main app. The filter for any new feature inside an existing app: (1) does it solve a real pain users already complain about, (2) does it overlap with your existing audience, (3) do you have permission from your brand to enter that adjacency? If yes to all three, ship inside the main app and lean on orchestration to surface it.
“if your business success is predicated on making it slightly cheaper to access what open AI offers or slightly easier you're in trouble they can and do change pricing and their UI and access restrictions and interfaces at any point”
Stop being a wrapper — be a focused solution
If your value prop is "slightly cheaper / slightly easier access to GPT," the platform will close that gap and your business evaporates. The defensible play is the opposite: pick a specific user (estate planner, bridesmaid speech writer, podcast publisher) with a specific workflow, and use the model as one ingredient inside a tailored end-to-end product. Wrappers compete with the platform; focused solutions compete with the customer's current way of doing the job.
“look at how many specialist hosting providers exist for web apps right if it was just about saving the most money every single person would host on AWS but in reality people have different preferences they want more than a generic platform”
Niche solutions exist because cheap-and-generic does not fit most people
Every layer of infrastructure has both an AWS-style raw platform and a thriving ecosystem of specialist tools (Vercel, Render, Fly, Railway) built on top of it. AWS hasn't "killed" the specialists — it enables them. The same logic applies to OpenAI: there is room for hundreds of specialist tools sitting on top of one base model because users buy fit, not raw access.
“no more spending time trying to manage embeddings and providing context from these embeddings we spend a ton of time building this in house now everything is about to become a simple parameter in an API call we can delete a lot of our custom code”
Platform feature drops often help you — they delete your custom code
When the underlying platform ships the feature you were duct-taping together, panic is the default reaction — but Banua at SciSpace welcomed OpenAI shipping native embeddings/retrieval because it deleted months of custom infrastructure his team was maintaining. Reframe platform releases: each one collapses a layer of your engineering cost, freeing you to invest that capacity in features the platform will never build.
“for every customer who makes such a speech you can add a new record into your database over time you can then use more AI internally to learn what good speeches are made of... you may not control the means of production you don't have the AI it's not yours but you own the ingredients the recipe and the finished product”
Your real moat is data + audience, not the model
You don't own the model — but you own everything around it: the inputs, the prompts, the output ratings, the customer communications, the audience around the problem. That data set + relationship gets richer every customer; the model on its own does not. Track what you uniquely accumulate that the platform never sees: corrections, preferences, segment outcomes. That is the asset that survives any platform pivot.
“for those founders with a low risk tolerance well consider generative AI tooling as a feature maybe not the core of your product... you can also diversify open AI isn't the only platform... if you have a high appetite for risk as a business owner you can build products using open AI tools and then try to monetize them very quickly”
Match your platform dependency to your risk tolerance — pick one of three tiers
Three explicit tiers to choose from with eyes open. (1) Low risk: AI as a feature inside a product that works without it — your business survives any platform change. (2) Medium risk: abstract over multiple providers, possibly self-hostable, so swapping providers is a config change. (3) High risk: go all-in on OpenAI and race to monetize while the wave is breaking. None of these is wrong — but mismatching tier and risk appetite is.
“industry specific data Transformations or workflow Integrations that are really nitty-gritty it's not what open AI cares about but you can do this and your customers will thank you for it”
Ship the nitty-gritty workflow features the platform won't bother building
OpenAI's core business is training and renting a general model — they have no economic incentive to build bulk PDF import, white-label embeds, vertical workflows, role-specific UIs, or industry-specific data transforms. Those are exactly the features that turn a wrapper into a real product. Build the integration ugly-edges your specific customer hates doing themselves — that's the moat the platform is structurally unwilling to fight you for.
“some platforms are really bad at you know at at cannibalizing their own uh apps so Shopify is terrible and Twitter is terrible and meta really doesn't give a crap... most of the other ones are are better at it right sales Forest HubSpot uh you know what Zoho zenes fresh desk intercom like it's pretty rare you hear about someone one of those ecosystem smoking someone”
Pick platforms that do not cannibalize their app ecosystems
Platform risk is not uniform — pick the platform deliberately. Shopify, Twitter, and Meta have a strong track record of absorbing successful third-party apps into core platform features (or killing them outright). Salesforce, HubSpot, Zoho, Zendesk, Freshdesk, and Intercom rarely steamroll their app ecosystem. If step one of your stair-step is a plugin, lean toward the second list and accept the platform risk for the 1-3 years it takes to climb off.
“by the time I left drip in 2018 I believe we were getting 175 feature requests a month... you have to say no to 90 plus% of those... here's the next five things we're building we got a request for this do you think I should bump any of these because then there is it's not just yes they can't just say yes they have to bump something else”
Say no to 90%+ of feature requests — force a road-map trade-off
Drip received 175 feature requests per month. You cannot ship 175 features per month — you can ship 5. The mental tool: never ask customers or advisors "should I build X?" (the answer is always yes). Show them the current top-5 roadmap and ask "should X bump one of these — and if so, which one?" Now they pay a real cost to vote, and you get a usable signal.
“I went through every single existing app looked through all the reviews of the things like what do people like what do they not like what do they wish they had... take all that and give it to Claude or Chat GBT and have them come up with your app idea so that you have at least a foundation of what you want to build”
Mine every competitor App Store review through Claude as your v1 spec
Before you write code, scrape every review from the 3-5 closest competitor apps and dump it into Claude with three explicit prompts: what users praise, what they complain about, and what features they wish existed. The wish-list bucket is your differentiated v1 spec — the market has already told you in writing what to build. Pat references another founder who applied the same loop (reviews + Stripe cancellation reasons + support tickets) and grew 350% after the rebuild.
“Marketplace are a people business so this is kind of the the background that you need to have to to build a business like that... Marketplace are a wonderful business because you you don't need to build a ton of features you just need to build out the people”
Marketplaces are a people business, not a features business
Coming at marketplaces from a typical SaaS founder mindset (build features, sell features) is exactly why bootstrappers fail at them. The product is intentionally slim; the work is recruiting, vetting, and curating the human supply side. If your strength is software/design and not people-work, marketplaces will fight you. If your strength is community / audience / sales, marketplaces are a perfect fit — even with little coding skill.
“Mentor Cru right now I would call it feature complete you could say like it's a perfectly fine marketplace... I'm actually the only one writing code and I do it about two days per week maybe not even... we get by by doing maybe like 10 hours of coding per week as a company”
Declare your marketplace feature-complete and invest in systems instead
MentorCruise as a 5-person, ~$40K MRR business writes roughly 10 hours of code per week total. The trap is treating the marketplace like a SaaS and shipping endless features. Instead, get to feature-complete fast (booking flow, chat, billing, dashboard) and reinvest the engineering capacity into operational systems — moderation, vetting, mentor success, billing edge cases. Each system improvement benefits every user; each feature usually benefits a handful.
“Okay Cupid... used to be a pretty complex product that made it possible to find very interesting romantic matches... over time it devolved into something more like Tinder a pretty simple swiping app that does not create deep connections... they had to cater not to the existing users but to their growth metrics to get new people”
Beware the marginal-user trap — chasing the next signup degrades the current user
When a product grows, the next signup is statistically less sophisticated than the last one — and growth-team incentives push you to optimize for them. OkCupid started as a deep-questionnaire matchmaker and became a Tinder-like swipe app because each new cohort needed simpler UX. Every feature you simplify for the marginal user nudges power-users toward the door. Catch yourself before you ship the third "make this easier" feature in a row.
“the highest chance of feature adoption and customer retention comes from features that align with the job that the customer needs to do with the tool... features that did something outside that scope were often ignored and complained about like we considered integrating other systems that they may have used or building communication features between teachers but those things were underused or unused at all”
Build only features aligned to the specific job-to-be-done your tool exists for
Audit every feature request against the single job your tool solves. FeedbackPanda existed to help teachers ship written student feedback faster. "Communicate with other teachers" sounded reasonable but had zero adoption — outside the job. "Share feedback templates across teachers" sat directly inside the job and exploded adoption + network effects. The pull to add adjacent features is always there; the discipline is to refuse anything that doesn't make the core job faster or easier.
“any feature that makes this easier is a strong candidate to be built early so for inputs just look for features that add ways to connect and make connection easier to the things that come before and for outputs add new formats that follow-up tasks expect or can deal with more easily”
Prioritize features that improve workflow inputs and outputs over standalone ones
Your tool lives inside a chain of other tools — what comes before, what comes after. Features that improve the join between your tool and the upstream/downstream steps compound the most. Import filters and integrations for inputs; new export formats (SRT subtitles, CSV, API webhooks) and enrichments for outputs. Standalone bells-and-whistles that don't touch the workflow boundary almost always underperform integrations.
“is it a job to be done that you're currently solving does it fit the scope of the problem that you're trying to solve is it part of a workflow and does it improve integration into existing processes does it change or simplify input methods or is it enhancing your output adding new ways to export results... the more of these criteria your feature fits the more likely is that you should go ahead and build it”
Run every feature request through this 5-question filter before you build
Before any feature gets on the roadmap, check it against 5 yes/no questions: (1) does it serve the core JTBD I'm solving? (2) does it stay inside the scope of my product's promise? (3) is it part of the customer's workflow? (4) does it improve a workflow input or simplify a connection? (5) does it improve a workflow output or enrich downstream-tool integration? 3+ yes = build it. 0-1 yes = decline politely. This single checklist will kill 80% of incoming feature noise.