Better Conversations over Perfect Docs
Stop polishing and start talking: Real dialogue builds better teams and products.
How many times have you been caught in this cycle: write an amazing PRD, hand it off to engineering, but something mediocre ships? We shoot for the “perfect” requirements document, the flawless spec, thinking if we just nail the details, the right product will magically appear. But we’re wrong. Documents like specs and PRDs are terrible ways to communicate and build products.
I’m imagining a canonical product development process: Goal/strategy selection → Problem/opportunity identification → Opportunity selection → Solution identification → Solution selection → Design → Development → Deploy → Release.
I believe we need to prioritize conversations over documentation. What if we used artifacts not as replacements for talking but as springboards for it? Often, the most successful teams aren't the ones with the best docs but the best conversation at every stage.
Almost 10 years ago, I was brought into a small tech company as their first PM and product leader. That’s right: no formal product management, but somehow, they’d amassed 10 million MAUs. The first time I visited the office, I saw them practicing what I’ve come to call “prairie dog product management.” Someone would have an idea, they’d stand up and just say it out loud. Another head would pop up over the cubicle wall, and they’d talk. Because everyone—engineers, QA, designers, and CSMs—understood the company goals and strategy and all knew the users well, they had a quick conversation. They poked holes in the idea, examined tradeoffs, and tossed around ideas for implementation. Sometimes they decided to build it and sometimes they didn’t but the process was easy and fast. If there was something to talk about, they’d just have a conversation.
While that particular model had plenty of flaws (they struggled to build big things, and when they did make big bets, they often were poorly tested in advance), that image has stuck with me as a model for deep engagement between Product and Engineering.
Let's take a step back and rethink the purpose of documentation, especially if you're a PM in tech. It's way too easy to fall into the trap of viewing our artifacts as the primary deliverables of product management. Common examples include:
The classic Product Requirements Document (PRD), often trying to cram in everything from Problem/opportunity identification through Solution selection.
Google Docs stuffed with specs and notes.
Linear/Jira tickets detailing user stories and tasks.
Miro/FigJam boards from brainstorming or mapping sessions.
Clickable prototypes showing flows.
But the real goal shouldn't just be to dump information into these artifacts passively. Good artifacts provide affordances for better, earlier conversations between engineering, design, and other stakeholders. Discussing complex trade-offs during Opportunity selection or Solution selection – like hashing out different login options (username/password vs. 2FA vs. passwordless) – needs an honest back-and-forth, sparked by the PRD or spec, tapping into everyone's expertise. That doc, no matter how detailed, will fail if it’s seen as the final product.
Shooting for “perfect” docs before talking to engineers isn't just flawed, it can blow up in your face, especially at handoffs like between Solution selection and Design. Part of the problem is just the nature of written communication itself. As Jeff Patton frequently points out in his book User Story Mapping, documents stink at creating real shared understanding. Think about it:
Written words are static; they lack the immediate give-and-take of conversation.
You lose all the vital tone and body language cues.
It's incredibly easy to misinterpret things, with different people walking away thinking completely different things.
Do you remember the first time you read Harry Potter? In your head, you pictured Harry, Hermione, Dumbledore, the cubby under the stairs, the sorting hat…all of it. Those books have incredibly vivid, descriptive, evocative writing. But I can guarantee the picture I saw inside of my head differed substantially from the one inside yours.
That spells trouble down the line during Development or Deploy. Writing more doesn't guarantee everyone’s on the same page. You risk falling into the trap of believing the artifact itself ensures alignment across the whole lifecycle, when it often fails to connect the dots between minds. Instead of endlessly polishing that doc in isolation, use it – warts and all – to spark the crucial, high-quality conversations needed to build actual shared understanding early and often, from Goal selection to Release planning.
Who needs to be in these talks? Your engineers, especially as the team dives into Design and Development. They usually have the deepest technical expertise in implementation. Instead of PMs dictating the tech specifics during these later phases, tap into their wisdom and experience. Get them directly involved in figuring out the best way to do it. Some teams might debate feature trade-offs when building a login system (security vs. performance vs. user acceptance) during the Design stage. At Google, I saw teams hiring designers to develop and film evocative product advertisements to clarify product vision before Development kicked off. One of my clients, a graphic designer, made a comic strip. There are countless ways to engage the entire team.
It pays enormous dividends to pull engineers “leftward” in the process, looping them in much earlier – starting from Problem/opportunity identification through Opportunity selection and Solution identification/selection. Looping them into talks about the company's vision (Goal/strategy selection), market needs, and user requirements during these formative stages lets you tap into their diverse experiences. Think about that login options example, but even earlier, during Solution identification, exploring choices like these together surfaces critical trade-offs only engineers might fully grasp before a direction is locked in:
Username/password
Two-factor authentication (2FA)
Passwordless login (like magic links or SMS/email codes)
Federated login (Apple, Google, Microsoft)
Using narrative tools like story mapping during Solution selection also helps engineers contribute to the “what” by questioning assumptions and shaping the MVP scope.
Getting engineers involved early means facing a reality they live every day: managing complex trade-offs. And this isn't just one phase; senior devs do this constantly, from weighing different approaches during Solution identification to making tough calls in Development. Figuring out the right balance – maybe between a quick-and-dirty solution versus a 'military-grade' one during Solution selection, or dealing with tight timeline pressures during Design – doesn't happen in a vacuum. It takes real conversation, backed by solid technical understanding, to navigate these choices effectively throughout the middle stages of the lifecycle. Oftentimes, the result is a desperate DM on Slack and the realization that until you answer their question, engineering has slowed to a halt.
Naturally, none of this works, at any stage from Goal selection to Release, if people don't feel safe speaking up. If you're a leader, you've got to be hyper-aware of your impact. Your team reads your cues like kids read their parents' moods. Tiny things can instantly shut down valuable questions or pushback, whether you're brainstorming during Problem identification or debugging during Deploy. Watch out for things like:
A thoughtless word that dismisses an idea.
A tone suggesting impatience.
Negative body language (eye-rolling, checking your watch, checking your email – we see you!).
Making an environment where people feel genuinely safe asking questions, challenging assumptions, and voicing concerns is absolutely non-negotiable for real collaboration across the entire product development process.
With a safe space established, how do you actually drive these discussions, particularly during Solution identification, Solution selection, and Design? My favorite model is user story mapping. Fantastic technique. Imagine your team is building a tool to help with “waking up and going to the office” – breaking down a process invites interaction as the team defines the solution. Consider steps like:
Alarm goes off
Stand up
Shower
Get dressed
And the clarifying questions that pop up:
When does shaving happen?
Breakfast at home or grab something on the way?
How's coffee getting made?
You can actually represent this with stickies on a wall (or the equivalent online). And when an engineer jumps in with, “Wait, not everyone drives!” it sparks a crucial discussion. Maybe you refine the Ideal Customer Profile (ICP) or simplify the Minimum Viable Product (MVP) during Solution selection or early Design. That's collaboration in action.
Story mapping clicks partly because it leverages the power of stories, which are gold in early stages like Problem/opportunity identification through Solution selection. We're just wired for stories. Instead of dry requirements during Solution identification, framing the work with a narrative – detailing the user (hero), their world (setting), and their struggles (obstacles) – makes the “why” way more relatable. Picturing that person rushing out the door, trying to decide if they’ll get coffee at work or on the way, adds clarity to everyone’s thinking.
Stories are great, but relying only on words can lead to everyone having a different movie playing in their head – think back to the Harry Potter analogy. The moment we all saw the movies, we suddenly shared an identical picture of Voldemort. That's why adding visuals is so crucial, particularly from Solution identification through Design. A visual artifact, like that fake Google ad concept or hand-drawn comic strip, gives everyone a shared picture that:
Clarifies the product vision during Solution selection.
Gets everyone on the same page heading into Design.
Sparks better, more specific questions before Development begins.
How do you bake this conversational approach into your process, especially bridging that critical gap between Design and Development? One powerful shift? Try engineer-led user story creation. Instead of the PM slaving over every detail after Solution selection or Design, the PM provides just a high-level epic (here’s my template):
A user-centric narrative (Jobs-to-be-Done, hero/goal/obstacles, whatever works for you).
Key non-functional requirements.
Placeholders for or links to mockups and prototypes.
Then let the engineers break down that epic into specific user stories as they plan Development. They usually have the best gut feel for how to slice up the work logically, and this process inherently delivers key benefits:
It forces questions to smoke out ambiguity.
It creates natural feedback loops for alignment before coding starts.
The job isn’t writing PRDs. You don’t get credit for specs, and your company will never be acquired for its JIRA backlog. But I believe that if you replace written artifacts with better conversations, earlier, you’re much more likely to build a product and company that are truly valuable.
Want to learn more?
The best book on the topic is User Story Mapping, by Jeff Patton. You can find links to the book, presentations, and articles at https://jpattonassociates.com/story-mapping/.
My example product, something to help with getting up and getting to work, was taken from a presentation I give, “User Story Mapping or Partnering with your Devs," which you can find here.