Tag Archives: PRD

RIP PRDs. Long Live “Agile Conversations”

I don’t write PRDs.

Product Requirements Documents.

They take too long to write and are typically outdated by the time they’re “finished”, which, it turns out, they never are.

They’re never finished because the market changes. Customers’ needs evolve. Competitors change conditions. New technology changes everything.

Worse, they typically end up creating even more documentation.

Years ago, I worked in a company that followed a pretty typical waterfall process. Product Managers produced PRDs. (MS Word docs.) Big, multi-page docs that contained sections like “Product Overview”, “Business Objectives”, “Features”, “Personas”, “Use Cases and User Scenarios”, and a detailed itemized list of “Functional Requirements”.

Then Business Analysts translated them to “Functional Specifications”. (A bigger MS Word doc.) And then a System Designer translated those to “Technical Design Specifications”. (Yet another even bigger MS Word doc.)

Crikey, we weren’t building an aircraft carrier! We were just trying to build a software app.

Imagine if something had to change in the PRD? (Which it always did, of course.) That change had to get propagated down to each document.

More writing…

But here’s the funny thing: these documents never seemed to reduce the need for the humans involved in the project to talk to each other.

Each of these documents were typically followed by meetings. Meetings to discuss the very documents that were produced. To go over them page by page, line by line.

Going over such a large document takes time. So we’d schedule 3-hour, 4-hour, 6-hour meetings. (No kidding.)

But no one likes long meetings. So after a minor outcry, these meetings were reduced to 1.5 to 2 hours tops. The result was the poor Product Manager (or Business Analyst or System Designer) was now pressured to run through the same big document in less time.

Of course, it didn’t mean people had fewer questions, though!

So inevitably we’d run out of time and have to schedule a follow-on meeting to get through the rest of the document and answer questions we weren’t able to get to.

It’s not easy to coordinate the schedules of so many busy people…

Net was the original 3 or 4-hour meeting was now spread across multiple sessions that took place over several days or even weeks, and we ended up spending more time in total.

More time in writing and discussing documentation.

This could take weeks. Often, months.

And don’t get me started on the “change request” process!

And with so much time spent in writing and discussing the documentation, you’d think the output — the actual product that was delivered — was built as expected.

Nope.

It was amazing how often, despite all the effort invested in documentations and meetings, some particular piece of functionality wasn’t delivered as originally envisioned.

So often it would be due to some disconnect between the various documents everyone was trying so hard to keep synchronized.

I swear, it would make me want to rip my hair out (of which I seem to have less of with age!).

We spent so much time producing, coordinating, verifying, validating, and CYA-ing the documentation that we didn’t do the thing that was most important:

Delivering value to customers as quickly as possible.

Our time is better spent interacting with customers, testing solutions delivering product to them, getting their feedback, and acting on that feedback as quickly as possible.

After going through this one too many times, I vowed never to do it again. That’s when I began experimenting not only with agile software development practices, but customer development and other lean strategies to test, validate and iterate on the business planning aspects of delivering software and digital products and services.

Over time, I’ve developed a more lightweight, human-friendly, and — yes — agile approach to testing, building and launching products. One that has a proclivity toward action and conversations, is fueled by customer centricity, and is predicated on delivering business value and speed-to-market.

To be honest, this approach isn’t particularly revolutionary, and I certainly can’t lay claim to having invented any aspect of it. It’s all pretty much what’s covered in the manifesto for agile software development, and the good news is these practices are being increasingly adopted in different companies and industries for different types of software products and digital initiatives.

And yet, every week I get an email like this:

“As you preach, long MRD/PRD’s make no sense. However, there is some need to provide our business analyst with some form of requirement. What do you do in these cases? I have a Feature Requirements doc I created, but I sometimes feel it is overkill. What would you recommend?”

People are increasingly aware of agile and lean practices. The agile manifesto is in the public domain. There are books on Lean Startup and customer development practices. But what this email (and countless others I receive) shows is that it’s one thing to be aware of a thing, and it’s another to actually put it in practice.

In fairness, that’s understandable. For one, people have different learning curves, in aptitude and even willingness to change. Old habits can die hard. There are also different environments, organizational structures and cultures to consider. Innovating in a startup is different than innovating in a global enterprise company. And then there’s special snowflake syndrome.

I’m on a mission to help as many of these product managers as I can. In my reply to this product manager, I shared the specific practices, activities and tools my teams and I use to replace the overblown PRD process. And I want to share them with you.

Here’s my reply (almost entirely copy-pasted here):

  • I no longer write MRDs, PRDs, or any sort of traditional functional spec. Haven’t written one in years. I don’t have my teams write them either. They’re a total waste of time.
  • If we have time, budget and bandwidth, we’ll always get a Designer to create the screens before getting it to Engineering. Doing otherwise is a waste of Engineering’s time. Only caveat is I keep my Engineering Head / Chief Architect informed and involved.
  • Since the Designer is the initial recipient of the stories, we can write them at a fairly high level. We don’t get hung up too much on granular acceptance criteria — the use case, user goal or job story is much more important at this stage.
  • As such, at times we’ve provided just a 1-pager with bullets. Because design is iterative, we lean more heavily on interactive ongoing conversations than documentation.
  • If we don’t have time, budget or bandwidth for a Designer, PM just hacks the screens — Balsamiq, ppt, whatever. Not ideal, but sometimes you just have to make do. I’ve literally sent a photo of a whiteboard doodle, and written the story around it.
  • As much as possible, for major new features or flows, we will do customer validation. Yep: phone interviews with screen shares. 5 may be good enough.
  • We don’t have a Business Analyst, so PM writes the stories directly, including me. It’s not hard, and removes a middle man. Not saying a BA/BSA is never needed — just saying in our case we haven’t had the need for one, and have managed fine.
  • When ready to provide the stories to Engineering, we do write more granular level stories. Granularity is determined by the detail put into the screens. Let’s say we had a designer mockup every detail — every click, button placement, font, color, and even copy —then it’s just easier to add the mockup as support documentation and point to it in the acceptance criteria. If the design was more high-level, like a ppt hack or my silly whiteboard doodle, naturally I need to provide more specificity.
  • We use Aha.io to capture ideas, convert them to features, write stories, attach supporting artifacts, do prioritization, and map out an executable roadmap. It has some super cool features:
    • It will spit out a req doc from the stories you write. This is helpful if you’re using a 3rd party dev firm and need to provide them a written doc during the initial planning stages. So we no longer need to use MS Word.
    • It has an awesome Jira integration feature: I literally click a button and — boom — everything is automatically placed in the Jira backlog.
    • It allows me to publish out status on our roadmap execution to senior execs. This is extremely helpful, as it gets me away from PowerPoint and Excel crap.

Ultimately what matters most is joint understanding between Product Management and Engineering (and Design, if you have it). If there’s a good relationship, all sides can come to an agreement on how the reqs should be delivered. And remember: regardless of how the reqs are documented, ongoing conversations between PM and Engineering is the key.


Are you still writing PRDs/MRDs? Or have you moved on to more effective processes? Share in your experience in the comments below.