A Robust Framework for documenting / reviewing Product Requirements

Thanks to Philip for his feedback on my previous post on design, this is a post dedicated to documenting & reviewing Product requirements.

I would recommend this article for professionals in business (Marketing, Sales, Operations) as well as  Tech ( Product, Design & Engineering) Functions.

Background 

All of of us in the tech domain want to build more meaningful products, that solve the problem at hand, move the intended metrics and do so in the minimum possible time and effort, maximizing the ROI.

The responsibility of making the above falls on the Product Manager, Engineering Lead and the Design leads of a Product. I personally believe in the “PM  = CEO of the Product” philosophy and hence I expect a LOT from the Product Manager.

If we were to imagine that the Product Manager is running his own little startup, I prefer looking at engineering & design bandwidth as her limited reserve of funds / capital.  She rather plan the bandwidth spend very very judiciously or bear the consequences of a failed product / poor ROI on her team’s efforts.

Managing Priorities &  Defining requirements for the right product capabilities are her biggest responsibilities and deserve a LOT of hard work and attention. Of course both of these activities need a bunch of activities to happen like user, market research, interviews, observing metrics, insights, trends etc. but the ultimate goal is to move the intended metrics with the help of building the right experiences and tech capabilities.

Managing Priorities: 

Have made a few posts in the past on Macro and micro level prioritization.

Defining Requirements

Requirements take a lot of time define properly and all of us try to take shortcuts and want to get stuff out faster, this is where its important for the reviewer to make sure that the shortcuts (if any) are well acknowledged and risks understood and if the given product / feature is really critical from a business standpoint to get right in the first or second iteration – you better do your homework properly.

High Level Process Workflow

Its 2 broad stages –

  1. Concept Definition & Validation stage
    1. Goals,
    2. Metrics,
    3. Users & Use cases
    4. Concept.
    5. Review and validation of the above with business / users and collaboration with engineering & design teams.
    6. Make sure you do thorough reviews at this stage to make sure any obvious issues are caught early and both engineering and design teams contribute and align on the high level approach.
  2. Product Requirements Detailing stage
    1. Scenarios
    2. Stories
    3. Designs (wherever applicable)
    4. Future thoughts
    5. Cross Product / System Impact Analysis Checklist.

Lets go over these one by one.

Element #1 – Goals (Elevator Pitch)

  1. This is where your interviews with your business stakeholders / users/ analysis of the data would come into play.  Feel free to quote the user pain points & data points that makes the business case.
  2. Business Goals: define the expected business outcome/ business objective to be met.
    • Goal 1  – <140 characters>
    • Goal 2 (if any) – <140 characters>
  3. User Goals: Define what user problems are to be solved.
    • Goal 1 – <140 characters>
    • Goal 2 ( if any) – <140 characters>

Element #2 – Success Metrics

  1. Define the top 1 or 2 metrics you would like to see moving.
  2. NOTE: whosoever is the proponent / champion of a particular feature or product should take a stab / be convinced with the projected metric movement. For example – if the PM is pushing for a particular new fancy shopping cart experience for her B2C product – she should down put down a metric movement number she feels confident about, similarly if its a B2B use-case where certain efficiencies growth is expected – the business user should help in identifying the projected improvement.
  3. This is a very critical exercise, sometimes doing this exercise pushes a previously important looking feature down down in the priority list.
  4. Put down the current state of those metrics and the expected future state.
  5. Tip: Make sure you a metric thats closest to revenue / cost (if not one of them). It might be one level or 2 levels down from Revenue / cost but not too deep. Picking / targeting the right metric brings a lot of clarity for the entire team collaborating on this Product / Feature.
  6. Potential Template –
Which business metric should move ?
Current state of this metric (before go live)
Expected state of the metric (after go live)
Comments/Assumptions
<Metric Name 1>     Example- X dollars / month  Example – Rise by 20%.  
<Metric Name 2>   Example- Y mins / session  Example –  Rise by 30%  

 

Element #3 – Users and their use-cases – today &  tmrw.

  1. This is a mix of 3 things – identifying the list of your users, what do they do today and what do we expect them to do at a high level tmrw if were to solve their problem.
  2. Your thorough user research should get captured here.
  3. Here is a potential template
User
Current Use-cases
Expected/ Future Use-cases
Camera Buyer (on an online camera buying platform)
  1. Searches for x’
  2. Finds ‘y’
  3. Makes a list
  4. Remembers their specs in his/ her mind or copies them into a separate excel sheet
  5. Compares – alpha, beta on the sheet / in her mind
  6. Finally buys y.
  1. Sees comparison of various models on the screen where she discovers ‘x’
  2. And / Or adds other models into the comparison bucket
  3. Opens the comparison bucket
  4. Finally buys y
User Type 2 (Say camera curation/ reviewing team)
  1. Tasks 1
  2. Task 2
  3. Task 3
  1. New Task 1
  2. New Task 2
  3. New Task 3

 

Element #4 – High Level Concept / Flow Chart

  • Put down a flow chart / designs on a paper / a few sentences that explain the concept / high level solution on paper and get that validated from your users.
  • This is where a lot iterations happen. Time spent here, saves a lot of it afterwards.
  • From a documentation perspective – Flow charts do a good job at this stage.
  • If you can come up with Concept Designs, that would make it even easier to do validation. Invest this effort depending on the nature of the feature.
  • Tip: LucidChart is a decent flowchart authoring tool and has simple JPEG and PDF exports available 🙂

 

Element #5 – Detailed Scenarios

  • I was not a big fan of this. I thought Dev/ QA doing this job should be sufficient, but have been proven wrong on this one.
  • These are nothing but various scenarios including negative and positive user actions, various entry points, various diversions on a user flow etc.
  • These scenarios would help the PM / team come up with an elaborate list of stories for the next section. Feel free to take Dev and QA help here.
  • I have come across situations, where an entire solution gets redesigned because of one missed important scenario 😦 , so highly recommend putting in this effort.
  • Sample template

Scenario

Expected Behavior

What happens when the user abandons the journey in the middle and returns tmrw ? 

What happens when he lands on this page without logging in and after logging in ? 

What happens if he types in in-correct mobile number by mistake ? 

 

Element #6 – User Stories 

A lot is available online on this one, here are my preferences –

  • Follow the format – As a <user>, I want <feature> so that <benefit>. Clarifies the feature context to everyone.
  • Break it down to specific sub-functionalities so that each story is fairly small and is independently deliverable / shippable (more or less).
  • Go into details and make it easy for engineers to understand. Don’t leave the stuff at a high level – going deep helps.
  • This is where you can add a sense of priority too.

Sample template

S.No.

Story Title

Details

Priority

1

As a user I want to login to see my emails

Elaborate and provide details about each of the basic acceptance criteria 1) Login 2) Log out 3) Forgot Password 4) Session Expiry ..etc.

High

1

As a security office, I want all users password to expire after 90 days so that password theft impact is mitigated.

Call out expiry details

Medium

 

Element #7  – Designs ( if applicable)

  • Having a hi-fi Prototype, tested on the ground is the ideal state on this one. Very hard to achieve though.
  • Wireframes are a bare minimum.

Element #8 – Impact Analysis Checklist

This is especially relevant if you are working with multiple systems that interact and depend on each other, impact of one tiny change in one system might break / have an impact on the other.  For example, a small change in the search ranking algorithm on an eCommerce portal might directly impact the earning / profits made by 3rd party sellers.

Its better to make a list of systems that are usual suspects for a particular system and make sure you have thought about each o of these while designing the above solution.

The reviewer of the document – should apply his / her own lens to ensure all the impact has been covered / thought out.

Sample template –

PRD Completeness Checklist

S.No. System / Activity Covered / Thought Through ?
1 Analytics / Tracking into Web Analytics  Yes
2 Impact on system ‘x’ Yes
3 Impact on System ‘y’ Yes

 

Element #9 – Future Thoughts

  • This section helps in capturing all future version thoughts. Provides an insight into the future for all the stakeholders and also forces the PM to define an evolution path for the given investment.

Additional Notes/ Resources

  1. Ballpark estimates – Getting the concept in place helps design and engineering teams with estimates that are so crucial for longer term planning
  2. Thinking about Go To Market / Post Go Live right upfront also helps a lot.  For example a nice cool feature doesnt help in creating PR if its hidden too deep inside. May be having an option to explore the nice cool thing on the home page might help.
  3. Here is a slightly dated & but an excellent post on coming up with meaningful product requirements by the Guru himself   – Marty Cagan on writing Good PRDs. 
  4. Update Marty Cagan’s previous post.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s