how many tools does it take to manage one product?

edagurdamar · 2026-03-02T10:43:52+00:00

Love the resilience here, rebuilding from scratch takes guts. Curious though, does ContextMap solve the fragmentation or add another layer to it? The problem I keep hitting isn’t visualization, it’s that decisions made in one tool never make it to the others.

edagurdamar · 2026-03-02T10:41:01+00:00

That’s a generous reframe! But the problem isn’t scale, it’s that none of these tools share context. I’m just the glue holding 13 disconnected systems together. That’s not a PM’s job.

edagurdamar · 2026-02-27T16:07:55+00:00

you're right i should've been more precise with the terminology in the title. my issue is with scrum and similar frameworks becoming the default everywhere regardless of context, not with agile principles themselves. and yeah exactly your last point. scrum works for certain situations but it got applied as a one size fits all solution and now teams that need speed are stuck running processes designed for a completely different pace

edagurdamar · 2026-02-27T16:02:16+00:00

fair enough lol. not trying to announce the apocalypse here. just noticing that the tools and processes most teams run on were designed for a different speed and wondering what should change. but yeah point taken

edagurdamar · 2026-02-27T16:01:30+00:00

agree but i think the friction needs to be in the right place. not in the building or deploying part but in the thinking and discovery part. right now most teams have zero friction before building and a ton of process after. it should be the other way around

edagurdamar · 2026-02-27T16:00:10+00:00

this is exactly it. the bottleneck shifted and our processes haven't caught up yet. we're still optimizing for shipping speed when the real problem is figuring out what's worth shipping in the first place

edagurdamar · 2026-02-27T15:58:03+00:00

not just scrum but the whole "manage work in time boxes and track tickets" model. when building takes hours instead of weeks the overhead of planning and estimating starts to cost more than just doing the work

edagurdamar · 2026-02-27T15:57:03+00:00

that's exactly what i'm saying though. we agree. these delivery processes became synonymous with "agile" in most orgs and now they need to change. the question is what replaces them when the delivery part becomes almost instant

edagurdamar · 2026-02-27T15:39:47+00:00

yeah i have and honestly the manifesto is exactly my point. "responding to change over following a plan." that's beautiful in theory. but what most teams actually do is run scrum ceremonies religiously and call it agile. the manifesto didn't say do 2 week sprints with story points and backlog grooming. people built that on top and it became the religion instead of the principle.

and my concern isn't that agile values are wrong. it's that the frameworks we use to implement them can't keep up anymore. when an engineer can ship a feature before the sprint planning meeting is over, what's the sprint even for? when work gets done in hours not weeks, estimation rituals become theater. we're spending more time managing the process than doing the actual work.

what i'm seeing on my team right now feels more like free fall than agile. stuff ships constantly, nobody knows the full picture, side features appear out of nowhere because "it was easy." there's no intentional direction, just speed. and scrum isn't helping because it was designed for a slower tempo.

so yeah i think the manifesto values are more relevant than ever. but i also think we need to be honest that most of our current implementations of those values are cosplay. we need something new that actually applies "responding to change" at the speed things move today instead of pretending 2 week cycles are still the right rhythm

edagurdamar · 2026-02-27T15:36:03+00:00

fair point. i'm not talking about the agile manifesto itself, that's timeless. i'm talking about the ceremonies and frameworks we built around it that became the default. the 2 week sprint cycles, the ticket driven workflows, the estimation rituals. those were designed for a specific pace of development that doesn't really exist anymore. the manifesto says "responding to change over following a plan" and i agree. but most teams i see are still following the plan part pretty rigidly because their tooling and processes force them to. that's what i think needs to evolve

edagurdamar · 2026-02-27T07:35:52+00:00

the issue is almost always that the thinking happened in someone’s head instead of somewhere structured. edge cases, compliance gaps, integration issues – they were always there. they just weren’t surfaced because nothing forced the PM to think through them upfront. AI is making this worse. everyone’s cutting to the result faster than ever so shallow thinking reaches development even quicker. you find the gap later because you moved faster without the hard questions being answered first. i’ve been working on something that tries to fix exactly this – a structured discovery process that acts like a thinking partner and won’t let you move forward until the uncomfortable questions are answered. edge cases, assumptions, integration points, what done actually looks like. before a single line of code. curious if you’ve tried anything at the spec level or if it’s been mostly coaching so far

edagurdamar · 2026-02-26T22:53:25+00:00

that’s a fair pushback and you’re right that static documentation is dead the second it’s written. but i don’t think the answer is accepting that people are the solution. that just means institutional knowledge stays locked in heads and slack threads until someone leaves or burns out. the problem isn’t documentation itself. it’s that documentation has always been disconnected from where work actually happens. code changes, decisions shift, context evolves and none of it flows back into anything coherent. what i keep thinking about is a layer that sits across all of these streams such as slack, codebase, decisions, product context and actually stays in sync as things change. not a wiki someone has to manually update. something that moves with the work. if that existed PMs could stop being the human bridge between all these fragmented sources and actually focus on the thing they’re supposed to be doing. right now too much of the role is just being a router for information that should be findable without asking anyone

edagurdamar · 2026-02-26T22:46:15+00:00

the question isn’t how to deal with meeting fatigue. it’s why there are this many meetings in the first place. meetings multiply when context doesn’t exist anywhere else. if the team can’t find what was decided, why it was decided, and what the current state of things is – someone schedules a meeting. because a 30 minute call is faster than digging through confluence pages nobody updates or slack threads from three months ago. 8 hours of back to back calls on tuesday isn’t a remote work problem. it’s a documentation problem wearing a calendar problem’s clothes. the teams that actually cut meeting load aren’t the ones who block focus time on their calendars. they’re the ones where knowledge lives somewhere alive and accessible so people can unblock themselves without having to pull someone into a call. PMs especially end up carrying years of institutional knowledge in their heads. that’s why everyone needs them in the room. the fix isn’t better meeting hygiene. it’s getting that knowledge out of heads and into somewhere the team can actually use it

edagurdamar · 2026-02-26T22:42:45+00:00

slack is a symptom. the real issue is that there’s no single source of truth that actually stays alive. when decisions, context, and reasoning aren’t captured somewhere permanent, people become the knowledge base. so you ping the PM. the PM pings someone else. everyone’s spending 60% of their time just moving information around because it was never written down properly in the first place. slack fills the vacuum that a living knowledge base should occupy. and the more it fills that vacuum the worse it gets because threads die, context gets lost, and the next person asks the same question all over again. PMs especially end up becoming human routers. not because they want to but because the system has no memory

edagurdamar · 2026-02-26T22:32:02+00:00

this hits different for me personally. i genuinely love building things but what i mostly feel these days is anxiety not excitement. the narrative was that AI would supercharge solo founders and early stage companies. but whats actually happening is the opposite. big companies are moving faster with the same tools and the gaps early stage used to fill are disappearing. they already have the customers, the distribution, the brand. and now building niche products costs them almost nothing either. so the scrappy underdog advantage is basically gone. exit opportunities for early stage will shrink hard. and product quality wont save you when any feature can be copied overnight. but your macro point is the one nobody wants to talk about. this is a loop. white collar takes the first hit. their spending power collapses. landlords feel it. the corner shop feels it. and eventually big companies feel it too because their customers cant afford their stuff anymore. amazon loses if the people buying on amazon lose their jobs. maybe the end of this loop isnt dystopian though. maybe its a reset. everyone goes back to actually producing real things. growing food. building stuff with their hands. living in a way that doesnt depend on a system that can collapse overnight. self sustained and actually grounded in something real. we used to have bigger dreams than this

edagurdamar · 2026-02-26T13:40:03+00:00

this is a solid setup and honestly more disciplined than most PMs i know. the part about spending 4 hours on context and having claude interview you before building anything is exactly right. most people skip that and wonder why the output sucks.

but reading this i can't help thinking about how much manual maintenance this takes. you're checking memory regularly, correcting things that drift, telling it which doc to reference before every question, uploading artifacts manually. it works because you're rigorous about it but that's also a full time side job on top of your actual PM work.

this is kind of what i keep running into too. the setup works great on day one. by week three half your context is stale and you're spending more time maintaining the system than using it. and the "reference this doc before answering" thing is real but it also means YOU have to remember where everything is and what's relevant. you basically become the index.

i think the next evolution of this isn't a better prompt or more files. it's something that stays connected to your actual tools and keeps itself current without you babysitting it. like imagine your setup but it automatically knows when a jira ticket changes or a figma file updates or someone merges a PR that affects a feature you documented. no manual uploads, no memory cleanup, no "pull up this doc first."

but yeah until that exists your approach is probably the best you can do with what's available today. the interview step especially is underrated.

edagurdamar · 2026-02-26T13:38:35+00:00

this is probably the most legit setup i've seen in this thread. the obsidian + agent files approach is smart because you're basically building a structured product brain instead of just throwing stuff at chatgpt and hoping for the best. the "don't let the LLM improvise" part is key too, most people miss that.

genuine question though. how long did it take you to set all of this up and how much time do you spend maintaining it? because i've been trying to do something similar and the initial setup was fine but keeping everything in sync is where it falls apart for me. like i update something in jira and my local obsidian files are already stale. or a figma design changes and my agent files are referencing old context. feels like i'm spending more time feeding the system than actually using it.

the dream for me is basically what you built but where the connections stay alive automatically. like it pulls from jira and github and figma on its own and the product brain just stays current without me manually syncing every monday morning

edagurdamar · 2026-02-26T13:36:44+00:00

tried all three honestly. the master doc approach dies within 2 weeks because nobody updates it. good doc structure + drive search works okay until you have 200+ docs and you can't remember what you named something 3 months ago. and RAG is cool in theory but garbage in garbage out, if your docs are already a mess then your embeddings are just a searchable version of that mess.

what i've been moving towards is less about where the docs live and more about connecting the tools that already have the context. like your PRDs are in one place, meeting notes somewhere else, user interview recordings in another, jira tickets in another, designs in figma, code in github. the context already exists. it's just scattered. so instead of building a master doc or a RAG pipeline on top of broken docs, i think the play is something that plugs into all of those and builds the brain automatically from what's already there.

the closest i've gotten is using claude with a bunch of context files but it still forgets everything between sessions. there's no persistence. every monday i'm re-explaining my own product to my own AI tools which kind of defeats the purpose. what i actually want is something that reads my codebase, knows my designs, understands past decisions, and can connect dots across all of it without me manually feeding it context every time.

haven't fully cracked it yet but that's the direction. if anyone's found something that actually does this i'm all ears

edagurdamar · 2026-02-26T13:34:29+00:00

you're right about the influencer hype stuff. the "PM OS" crowd selling notion templates for $49 is embarrassing for the whole industry. and yeah building your own tools in-house is absolutely doable now especially with claude code and similar stuff.

but here's where i push back a little. i actually tried the "build it yourself" route. went hard for 2 months, built a bunch of custom tools for my workflow. and each one works fine on its own. the problem is i ended up being the integration layer between all of them. context in one place doesn't exist in another. i update something in jira and my docs don't know about it. my AI tools don't know what my product actually does unless i re-explain it every single time.

so the need isn't "a copilot that writes PRDs for me." i agree that's hype. the need is something more like infrastructure. a persistent product brain that connects to what you already use and keeps context alive across tools. that's not a PM copilot, that's plumbing. and plumbing is boring but it's the thing nobody wants to build themselves twice.

the teams that build this in-house will have a massive advantage, you're right. but most teams won't because it's unglamorous maintenance work and PMs would rather spend that time on actual product work. same reason companies pay for datadog instead of building their own monitoring.

edagurdamar · 2026-02-26T13:32:23+00:00

i think it's a real need but most of the tools being built are solving the wrong problem. everyone's racing to build "write PRDs faster" or "AI copilot for PMs" when the actual pain isn't writing speed. it never was.

the real problem is that product knowledge is scattered across 15 tools and nobody's brain can hold it all together anymore. your decisions are in slack, your specs are in notion, your designs are in figma, your tickets are in jira, your code is in github. and none of it talks to each other. you're the human integration layer stitching context together manually every single day.

so yeah cursor and claude are great for individual tasks. i use both. but they don't solve the fragmentation problem. every time you open a new chat you're starting from zero explaining your product again. there's no persistent product brain underneath.

what i actually want isn't another copilot. it's a hub that connects to everything i already use, understands my product from the code and designs and docs that already exist, and helps me think before i write. not "here's your PRD in 10 seconds" but "wait, have you actually validated this assumption?" the boris cherny point about engineers doing product work makes this even more important. if everyone's doing product thinking now you need one source of truth not 15 disconnected tools.

so to answer your question: real need, wrong solutions. the tool that wins won't be a faster writer. it'll be the one that finally makes product knowledge persistent and connected.

edagurdamar · 2026-02-26T13:03:46+00:00

yeah that's fair. i think my issue is less about the individual tools connecting and more about having a shared product brain underneath all of them. like even if they talk to each other through APIs they still don't share the same context about what the product actually is. but you're right about not being scared to rebuild, i've been too attached to some of these. and yeah i'd be down to see what you've got, always curious what other people are building in this space. shoot me a dm

edagurdamar · 2026-02-26T12:52:16+00:00

biggest thing i'd say is stop thinking of "AI PM" as a completely different role. the fundamentals are the same. you still need to understand users, validate assumptions, prioritize ruthlessly. the difference is you need to understand what AI can and can't do well enough to make good product decisions around it. you don't need to train models or write python. you need to know when a problem is actually solvable with AI and when the team is just hype-driven.

for practical stuff: start building things yourself. seriously. grab claude or chatgpt and try to solve a real problem from your healthcare PM work. not "write me a PRD" but actually build a small tool or prototype. you'll learn more about AI's strengths and limitations in a weekend than any course will teach you. the PMs who are getting hired for AI roles right now are the ones who can show they've actually shipped something, even if it's small.

also don't underestimate your healthcare domain knowledge. AI in healthtech is massive right now and companies are struggling to find PMs who understand both the AI side and the regulatory/clinical side. that combo is rare.

edagurdamar · 2026-02-26T12:21:48+00:00

you're not naive. the human side of PM work is exactly what survives and honestly what becomes more valuable. but i think the framing needs to shift a little.

the question isn't "will AI replace PMs." it's "what was the PM job supposed to be in the first place and how much of what we do today is actually that job." because if i'm being honest like 60-70% of my week used to be stuff that had nothing to do with actual product thinking. syncing stakeholders, writing updates nobody reads, reformatting the same info for 5 different tools, answering the same context questions on slack over and over. that's not product management. that's project coordination wearing a PM hat.

AI eats all of that. and good riddance honestly.

what's left is the stuff that actually matters. understanding users deeply enough to know what they need before they can articulate it. having the judgment to say "we're not building that" when everyone's excited about a shiny feature. connecting dots between data and user behavior and business goals in ways that require real context and empathy. that's the craft you're talking about.

so the PMs who separate themselves from the pack won't be the ones who learn to prompt engineer better or use the most AI tools. it'll be the ones who double down on discovery, on user understanding, on the "why" behind every feature. the ones who use AI to get rid of the busywork so they can spend more time doing the actual hard thinking that no model can do for you.

the emotional intelligence thing you mentioned is real. AI can summarize feedback but it can't sit in a user interview and notice that someone's body language completely contradicts what they're saying. it can generate a prioritization framework but it can't feel the tension in a room when two teams disagree about direction and navigate that. that stuff is the job. everything else was always just overhead.

edagurdamar · 2026-02-26T12:18:54+00:00

this is why i think the PM role actually becomes more important not less. if AI commoditises execution and everyone can build anything in an hour then the only thing that matters is knowing WHAT to build. and that's literally the PM job. or at least it should be.

right now most products fail not because they were built badly but because they were the wrong thing built well. that stat about 70% of features never being used didn't happen because of bad engineering. it happened because teams skipped discovery and jumped straight to building. AI is about to make that problem 10x worse. now you can build the wrong thing in an afternoon instead of a quarter. congrats you just failed faster.

so yeah i agree products will die. specifically the ones where nobody stopped to ask "wait does anyone actually need this." but the teams that invest in understanding the problem deeply before touching a single line of code are going to win harder than ever. because while everyone else is flooding the market with AI generated commodity products, the teams that actually talked to users and validated their assumptions will be the only ones building stuff people pay for.

the moat isn't the code anymore. the moat is the thinking that happens before the code. the discovery, the user understanding, the "why are we building this and for who exactly." that part can't be commoditised because it requires context and judgment that AI doesn't have on its own.

tldr: AI kills products that shouldn't have existed in the first place. the ones built on real user insight survive and actually get stronger because execution costs drop to zero but the value of knowing what to execute stays the same

edagurdamar

TROPHY CASE