Monday, February 12, 2024

Design for sales not users

Focus on the User may not always help. It reduces your scope of thinking. Focus on selling might help. It's almost Amazon's "work backward" model applied to "designing". 

Creating designs for sales vs creating them for Users. 

I am saying DON'T BE USER CENTRIC ... (Don't shoot me yet)...for a little while. 

We are NOT talking about implementing a design that isn't user-centric. We are just keeping our protagonist on the side for a little while and working on the promo poster of the film. 

Thinking about users brings in a lot of clutter. 
There are typically a bunch of different things you need to think about:

1. What's the persona: who exactly is using this feature and why? 
2. What are they hiring this product/module/feature/screen for? 
3. The main flow, additional flows, error flows
4. Some navigation constraints like where are they coming from, and where can they go from here. 
5. A few product constraints around what information we traditionally have or do not have
6. A few constraints based on timelines, and scope 
7. Finally maybe some constraints based on the technical capabilities

So as a first step, we don't design for the user. We imagine our product already exists and users are using it. We need to simplify and show something that is clearly much simpler and can be used in a print ad or a TV commercial. With 4 out of 5 sponsors of all large tournaments in India being mobile app companies, it's easy to find inspiration for how people simplify their complex user interfaces for showcasing the use case in TVCs.

Example:
PayTM actual screen v/s the Screen on Ad 


 v/s


When you design for sales, you just want it to have the following:
1. It clearly states the value achieved by the user. 
2. It is aesthetically pleasing. 

I am not saying these can't be done in a user-centric approach as well. Just that it usually gets lost in the clutter, and what you get is a dull and boring design that functions really well. It's almost like you stack the cans, arrange the snacks, order the food and then forget to party. 

Starting by creating for sales helps you create some really great UI, that impresses. In fact, the first version of the product may look completely different from the UI you've created for sales. Well, it's not for the sales team to actually use it (while we do sometimes end up showing it during high-profile deals). It is for the product and design teams to use it for internal selling. We can call it a North Star UI. 

How to do it?

What is the final outcome/value achieved by the user?
What will the screen look like, at its glorious best?
What is the most relatable information/term/output on the screen?
What is NOT immediately screaming value?

This has helped. 
Try it, and let me know


if you don't find it helpful. :-) 


Wednesday, March 29, 2023

List of some speaking engagements I've had

Someone asked for links to any past speaking engagements and I was hoping to find a couple. To my surprise, there were a bunch available online. :-)

Most offline events are either not recorded or the recordings are never published online but here are some online and offline ones that were captured over the years and are available. 

Short Workshop on Idea Validation: https://www.youtube.com/watch?v=LHfCWY-eAIw,

Moderating a panel during Product Week (ADPList) - https://www.youtube.com/watch?v=lPSt6stl0wE

Snippets from Funnel Analysis Masterclass - https://www.youtube.com/watch?v=G8UFpYvEqZA

Live session on Product Management 101 - https://www.facebook.com/watch/live/?ref=watch_permalink&v=1084671915223183

Podcast on Product Thinking - https://pm-powerconsulting.com/blog/product-thinking-trifecta-with-ujjwal-trivedi/

Short Workshop: How to create MVP - https://www.facebook.com/watch/live/?ref=watch_permalink&v=884902488909378

Moderating a Panel for Headstart- https://www.youtube.com/watch?v=RxQi1Qd1vIQ 

Just keeping it here for my own quick reference. If you recently found this blog, you can skip these and go read some stuff here and on medium - would probably be more useful.  

Sunday, May 15, 2022

Product Management Learning Track @MoveInSync

Once upon a time, I thought I should start a product management course too. There are hundreds of cohort-based courses out there now, but I am talking about a time a little before PM courses were being sold on Fiverr. When they still seemed rare and valuable. 

I recorded the first PM-related intro video in 2015 for an ed-tech platform that doesn't even exist now. Over 2k people loved it and rated it 4.9/5 stars. If 2k looks too small a number to you, let me tell you that it would have been about 10% of the market share then. I was also consulting some big brands for setting up the curriculum for their upcoming product management courses. I also taught classes at some of those "very academic" courses - mostly delivered by folks who come from large corporates. I was invited for giving "practical" insights. So, it shouldn't come as a surprise if I had a feeling that I could do a few notches better than them. 

So, I planned the entire thing, but then, something wasn't adding up. I figured people buy what they want, not necessarily what they need. I strongly wanted to give them only what they need. Unpopular things like ignoring "RICE" and "MoSCoW" frameworks early on, and prioritizing by deeply understanding ROI. 

The guys who wanted to sell my course wanted me to do stuff that would sell. But, I figured I don't want to teach that kinda stuff. I actually did not want to sell at all, I just wanted to teach. I also know that anything done for free gets taken for granted. So, I could not do a free course either. 

Where could I get a sincere audience who would take stuff seriously without paying for it? 

EVIL PLANS

I once got a call from one of my reportees at MoveInSync. She was ranting about how she has been spending week after week firefighting. And I asked her if all this fire wasn't there, what was her plan of action. She had none. While she was puzzled, I was smiling - the smile you have when you get an evil idea. I had 10 reportees at that point and I could see all of them struggle with one thing or the other. Here was my audience. And a great opportunity, because we wanted to build a kickass SaaS product, that can have a "Global" appeal. 

One beautiful thing about MoveInSync culture is that it is very open. Thanks to my reporting manager Videh, at that point, for encouraging me to begin experimenting with a learning series for all young PMs. After a few experiments around a classroom-style model once a month, I figured it's extremely hard to maintain consistency by teaching a common topic to a diverse crowd. I wanted to do something that helps people subscribe to the learning, and not force people into it. 

So here are the details of what eventually worked (and is still WIP). 

12 SKILLS, 12 MONTHS

Some numbers just fit. I found this popular blog from Ravi Mehta. 


It talks about 12 skills that a PM should possess and practice and how the expertise required in each skill changes as you ride up the career path in product management. As you'd have guessed 12 skills in 12 months looks like a perfect fit. 

Without getting into the debate of the accuracy of this, I'd tell you how it became immediately useful. It was a good way for everyone to do self-evaluation and identify what skills would they want to work on. 

And so, we planned a monthly one-to-one check-in with me - where everyone will review themselves on all 12 params. I'd discuss my evaluation of their skills and gaps. Then we mutually decide what they'd like to focus on learning in the next 1 month. 

Monthly plan

  • Learners should decide and announce what skill they'd focus on learning. 
  • Learners should then study the topic and eventually apply it in their daily work. I'd help get them started with a list of books, podcasts, blog posts, and internet resources that I have saved for my own reference. These are usually things that I have re-read multiple times and have personally found very beneficial. Here's the index. Every time we decide on a topic I send them links from here. And of course, this is just a start. The curious folks, keep double-clicking on the right things and find their own treasures. 
  • They should take notes, take snapshots of "before" and "after" for things they seem to have clearly improved upon, and register it in the workbook (mostly a shared spreadsheet) so that we can discuss it during the next check-in. 
  • Learners should also plan to discuss the topic all through the month with peers and managers to internalize it and apply it effectively.  
  • At the end of the month, we looked at the notes, discuss progress in self-evaluation and decide what should be picked up next. 

This has been really helpful in improving the baseline of product management know-how for everyone in the team. It also gives people enough time and motivation to keep learning new stuff and to keep applying it. And probably I'd skip the part where I tell you how effective it has been for creating an amazing product culture at the organization. I am sure you can imagine it. 

NUANCES

This looks like a perfect plan, but, it isn't. 

  • Not everyone finds this 100% useful. So, it is OK if they would like to take up a different skill like Tech/Digital-Marketing - it can quickly be structured in a similar way. The understanding is that you are upskilling yourself and making defined, structured progress.  
  • Not everyone learns at the same pace. So one can be flexible. Remember there are no annual term exams at the end of the 12-month period. So, it can pretty much be self-paced. People can also take a sabbatical from this and join back the track at any time because everyone is working on their own set of skills. 
  • Not every skill is immediately applicable. There are some skills like documentation that you get to use every day, there are others like road-mapping which may not even apply to a team member (based on their designation).
  • Learning some of these skills (most of the last six) is subject to opportunities. Learning about team leadership is one thing, but actually leading a team of smart folks is another. You only get the experience, when you get an opportunity to do it. It may happen within the course of a year, and it may not. I strongly believe that success is when "opportunity" meets "preparedness". So while one may not get immediate opportunities, one should prepare for them long before one actually gets them. That's what I continue to do for my own learning as well. I read stuff and learn things that may not be immediately useful, but could be useful someday. Also, as a manager, I try to get my folks that opportunity in some form.  
I just thought I'd open source this initiative so that more curious PM leads in different organizations can build more useful, impactful stuff on top of this. 

I'd love to know if you do that, and/or if I can contribute further to your cause. 

--------
PS: Leaving a comment/question helps the author get the motivation to write more. SO DO IT!




Tuesday, January 11, 2022

After the ProductHunt Launch

What to do after launching on product hunt? 

This is what I looked for and figured that I was too late. And if you have launched the product without a lot of good preparation, you've missed the bus too. 

However, all is not lost and this post will still help you salvage the situation to some extent. Also, if you haven't yet - you're lucky. This is going to be a very powerful set of actions you can take immediately. 

CONTEXT

So our marketing team had a real good run with the listing sites like G2, Gartner, and the likes. And they thought they now know how things work. And hence one day I got to know that one of the noobs from the marketing team has hunted our product on ProductHunt. Facepalm! 

Despite our best efforts, we missed getting any meaningful ROI. However, every failure is learning. So, I picked up all the gyaan I could gather on the topic from successful Hunters and wrote a memo to my Marketing Team about what happened and what to expect now. I feel many other noobs could find this useful so I am reproducing it here. 

Here's the Memo: 

(Have removed some parts that don't make sense for a wider audience)  

Unlike listing and product review sites - PH is a LAUNCH platform. We chase a #1 Product of the day tag - and it's a 24-hour game. That's about it. If we get that badge we can use it for a long time. If we don't, we're done.  

We ended up being 12th on the day. The rating depends a lot on who's hunted the app and who is commenting on it. Upvotes also help - we did decent with the numbers, but we need more genuine upvotes, more meaningful conversation happening on the page, and finally more demo signups from the page. 

Next steps. 
This launch is done. Nothing more to do.

Next, we can launch new versions (after a few months), lateral products, and peripheral Products like (<some side product ideas, including case studies converted to ebooks etc> and all of them lead to the same landing page, etc. 

Here's what works better: 

1. Animated logo - gathers more attention. H/T @naz_09

2. Get hunted by one of the Top 10 hunters 

3. Prepare for launch - have a PH landing page that incentivizes upvotes (like a 30% off) for 3 months. 

4. Prepare for launch - have PH Launch e-mailer ready to be shared with existing and prospective clients so they can leave comments and hopefully upvote. 

5. Prepare for launch - Prepare employees to sign up on PH, and use it like they would use the platform. Instead of most people being new signups - only to gather upvotes. 

6. Prepare for launch - Keep social media and personal posts ready where we talk about PH launch on our social handles. 

7. Prepare for launch - identify top people in the category and reach out to them to check out the product and upvote/comment. 

8. We have to time the launch in a way that provides good overlap for both employees and clients. (6am EST is a good time) Also, doing it over the all-hands meet could be a good idea. We get 200+ live audiences on that.

9. And we have to ensure most people are not using office IP address, otherwise the traffic is probably discounted (no one outside PH knows what happens for real). 

More elaborate ideas on how to fill the form - https://medium.com/swlh/product-hunt-101-426511f03501 

HTH!

-------------------------
If you found this helpful, do leave a comment for the Author. Otherwise, you'd never make it to the #1 spot. 

Tuesday, February 16, 2021

Building Empathy as a product manager

Source: Oliver Clink

Empathy is the ability to conceive the right product for the right people at the right time while keeping the team super excited. Execution and delivery need much more than empathy - but that's for another day. 

How does one build empathy?

I've followed a lot of contemporary product guys and discussed with them what differentiates great PMs from others who also write documents, analyse data, coordinate with stakeholders and get things done? And the answers lead to their skill/ability to empathise with the user/ stakeholder/ reader/ audience/ team. I firmly believe, and it won't be hard to realise for you too, that how you do one thing is how you do everything. So you can't possibly be doing a great PM job for your users, if you aren't also empathetic towards your team and other stakeholders. 

While your job involves a lot of pushback and "Saying No", that's certainly far from meaning that you stop listening. You don't exist to pick battles and win them, you exist to create a balance in feasibility, viability and usability. The negotiation hat comes in only after you've been super receptive to what people need and want - not only from the product, but also from you (you are also a product). 

When you are being empathetic, it shows up in your communication, in the documents you create, in the designs you make and in the metrics your measure. 

Conscious effort to be empathetic is all it takes. Ask "why" and "who for" more often. You need to put it in daily practice. Here's a few things that can help you get better.  

Get deliberate exposure

Get out of the building

Get into the calls, meetings, visits where you can see, meet and talk to your users and understand them better. Make it a process. If you aren't going out of the building you'd never reach their heart. If it's not part of the process it won't happen regularly. 

Make it a process, put it on your calendar. 


Listen to feel

You are responsible for the emotion. You have to feel what they feel. If you don't feel pain, regret, guilt in a support call of a useful product, you aren't listening hard enough. If you aren't getting a lot of product ideas while thinking about the conversation, you aren't listening hard enough. Listen to what they say and also what they don't put in words. Look for patterns, if more than 2 unrelated users say the same thing - one should get alerted about a possible insight.  


Articulate user responses

Empathy Map

When thinking of your user's journey through a task - check at every step what the user Says, Thinks, Feels, Does. That's a great framework to understand the user and also to convey your understanding to the wise folks around you. 


Eat that dogfood

Source: Reddit

If you aren't using the product "like a user", you can't get it right. If you are creating something for a delivery boy, use the phone they use, get out in the sun/rain, drive with them. Unless you do that, your requirement gathering is incomplete. 


Forget your product

Forgetting is a superpower

This is powerful. How easily can you forget you have a product and articulate the exact problem your user is having. Don't try to tweak it in terms of the solution you have. We generally practice filtered listening, we note only what is relevant to our product, our beliefs, and our roadmap. A good indicator that you are able to forget the product when listening to a user is that you'd learn about 2-3 non-relevant problems of the user as well.  


Appreciate Art

A great way to be more empathetic is to improve your emotional vocabulary. Humans have 34000 emotions, how many you name? Refer to this amazing guide of Emotions. If you are able to observe your emotion and decide whether you are irritable or angry or disappointed, you help yourself win the emotion as well as get more empathetic. A good exercise is also to try understanding art - not just enjoying it. It could be music, painting, movies, poetry - or anything that you deem creative. 


--

Show the author some empathy, drop a line. 

Monday, February 1, 2021

How to transition in to a PM role?

Crossing the chasm!

That's one of the most frequently asked questions I get - How do I transition into a PM role or How do I break into Product Management?

Honestly, I don't know. But, I can tell you how I became one. 


Most advice is people giving you their winning lottery ticket numbers. 

- Naval Ravikant


There, Naval said it. So, why should I be an exception?  

I discovered the Product Management role in 2009 (while I was still a Techie), became one in 2013 - and there was no one to tell me anything about what it is like to be a PM - even after I became one. So, all my effort so far has been about making it a little better for the next set of folks coming into this role. 

Disclaimer: This post is for folks playing a long-term game, if you want instant benefits go to this place. Also, if you are already a PM read this. 

From a techie in a services company, my first jump into the business side of things was becoming a trial business analyst. I was a Techie for 5 years, an average coder, a much better team lead (my team told me later). In services companies, you don't need to be a crack hacker. I had the people and communication skills that services companies love. I understood what clients wanted, created great docs, engaged clients, and the team alike, and got shit done. 

One day in a small presentation room cum library cum dormitory, my career took a sudden twist. While I was presenting a case study in a typical management development program that services companies do for "young leaders",  my boss's boss saw me present and he felt I could be a fit for some business role he had in mind. So, we took a trial for 15 days and that was it. Got a chance and made the best of it. I turned from a Techie to a Business Analyst (and eventually a PM).  

They say it takes years for overnight success. And they are right. 

The story doesn't really begin in that small presentation room. It started much earlier when I was just a techie in a services firm. In the corporates, you can do brilliantly well, but your growth is mostly determined by the ominous bell curve. The only way out for a different growth path, as most people suggested, was to mortgage your balls to the banks and do an MBA. 

For someone who had just come out of the clutches of education loan debt, I was either too naive or too possessive about my balls. The freedom of being debt-free is addictive. I couldn't think of getting into bigger debt for education again. So, I decided to pursue what I could. I started to learn whatever was free. 

Enter Coursera. There were professors from Stanford and Penn teaching me marketing, business strategy, finance, and gamification. (The first 4 courses I took). And all for free. I couldn't ask for a better deal. Having collecting 100+ certificates for co-curricular activities in school and college I had a growing disillusionment for certificates. All I cared about was the knowledge and structure coming in video format - much better than reading a book. 

That said, I was quite a hoarder of books as well. There is nothing more spellbinding than the smell of old books on discount sale. That's what I miss from the tonne of ebooks I download. Leadership, Organization structure, Business stories, Physics, Advertising, History, Spirituality, Black magic - I like reading everything. If these things sound like a digression, you've missed the point already. 

The point being, it's hard and there is a lot of time, patience, and hard work required - and it is still based on chance.  

The best PM courses have eased the process a little but they are like all other courses in the world. They help you learn and leave you on your own to go figure. 

So what can YOU do?

Do what you love to do.

Unfortunately, that's it. It is as simple (or as difficult) as that.  

Did I tell you that I started writing blogs in 2006? 

I had blogs for Poetry, Cartoon, Advertising-critique, Business learnings, Newsletter. Some of them are still active, some died down - all are not so good, but I am still proud of some of the stuff I created. That's how I learned, by writing, creating, doing. I was part of a bunch of online communities and created a few of my own. I was part of the social media teams of all organizations that I worked for until it started becoming a specialized role sometime around 2013 (In India). 

While I was still leading a team, I was also doing all these other things - just because I love doing them. In most organizations I have worked with - if you are taking care of your work, anything you do over and above that, is welcome. It may not lead you anywhere. It may not get you the promotion or raise. It may not even get you the award that you deserve. But, it would give you a lot of learning and experience and satisfaction of doing something you love to do. 

At least to me. It did not get me any of those things - at that time. 7 years of toiling and doing stuff I wanted to - that was the reward. My first official appreciation/award came in 6 months into the product role. And then on, I've gotten it at all orgs I've worked with so far. And all the experience and learning come back together when I get into new problems and situations that no one can prepare me for. 

And, did I mention I started up? 

Twice. Among a bunch of other things I did, I also started a T-Shirts printing business on the side. Had huge plans but no real insight about how startups work. Also, I was working with two other friends from college time - all working on the side. We hustled for 6 months and then - "Jimmy quit, jody got married". So while it failed before it could really start - that was one of the most useful of my failures. The other two found their international MBA entry with this startup-failure story, and I still use that experience in product management. 

And, you know I volunteered. Right?

In 2014 I was thinking a lot about how to measure things correctly as a PM (or as anyone in business). How to measure growth, engagement, success for your products or processes? My quest led me to join the Headstart Network Foundation as a volunteer. I asked them how do they measure their impact, they said they didn't. I suggested they should. They suggested I should join them and do it. And that was it. Over the years, the Non-profit has grown and now I have a network of startup folks in 50 odd cities across India, Japan, Berlin, Finland, and London. Not bad for a non-MBA guy. 

Some of these have been strategic decisions, but, most of them I just said yes when the opportunity looked interesting. So, while as a PM we are asked to "learn to say NO", I've almost always taken up a new challenge by saying YES. There are no right decisions, you have to take a decision and then make it right. 

Ok, we've gone past a lot of stories in flashback and flash forward. Let me listicle it for your easy take-home. 

Here's a mad method to the madness:

PREPARE: Product Management sounds way cooler than it is. So stay cautious. It may not be for you, it's ok. Check out Customer Success (it's close and amazing). Or whatever else. 

GO WIDE: Product management is a lot of general management plus product instincts. So learn people management, leadership, software development process, basics of starting up. And build product instincts. Instincts are cognitive shortcuts that you develop over time by practicing something for long. So the best way to develop product instincts is to take a lot of decisions and get better at taking the right decisions. Even if you are not a PM, can you write your gut feel about the product and refer to it later to see if your gut feel was right? Thinking about how things around you work, and how can you make them better. How you'd improve an existing product - is a great exercise. But don't just think about it, ask others, read about it, analyze the competition, accumulate stats - have fun with it. If this sounds hard - it is hard, if you want it easy, go pray. 

APPLY: Do it. Do a lot of things to find out what you love to do, your calling, your spark (#soul), your ikigai - whatever. And once you know it, double down. 

BE CURIOUS: Learn something new. Hoard knowledge - read books, watch videos, listen to podcasts, follow amazing folks on Twitter. Don't try to do the "most effective thing" to begin with, figure what's most effective for you with trial and error. There are hundreds of great ones, don't even ask for "That one book". Have a 2-year plan. 

IMPROVE YOUR AVERAGE: Create a great network - meet people you find inspiring, try to ask them your questions, try to help them with something they might need - everyone is looking for something. They say you are the average of 5 people you hang out with most. It's probably right. 

GIVE IT AWAY: Share knowledge - a great way to learn is to write. Social media makes it better - adds some dopamine to the learning. You might think you have nothing to give initially, but keep at it. The attitude of giving back would help you find the right set of things to focus on.  

INTERVIEW: While the rest of it is critical, long winding, and DIY kind of approach, this is the only tactical advice I have. Work on your Resume, you can always improve it. Prepare for STAR interview questions and a bunch of other interview patterns listed on the internet and PM interview books. This is where all your other actions come together. Don't depend on your diffused knowledge alone - the way a lot of interviewers interview is crazy. Don't judge the company by one interviewer - but prepare really really well. Here's my framework on how to crack assignments. 

Drop me a line, if I can be of help. And if you think I can really help you further, feel free to book a timeslot here. (15 mins of ketchup is free) 

Sunday, January 3, 2021

World's Simplest PRD Template


So when it comes to the PRD templates, people try solving world hunger with it. In fact, that is also what general people try to solve with their products - and that's precisely why a PM is *required* - to find the method in the madness. 

PRD is a Product too 

Touché

Oh! How did you miss this? 

Your first Product is you, Mr. Product Manager (or your resume).  And the second one is what you are hired to manage and the third one is your PRD. 

If you aren't dealing with the PRD like a Product you are definitely either ignoring it or overdoing it. In either case, it's a major loss in your personal efficacy and the org is definitely suffering from communication gaps, expectation mismatch, team battles between tech and non-tech stakeholders. 

So a simple and obvious solution is to create a comprehensive PRD that has everything any stakeholder would ever need. Besides, that's not a solution. It's just that same, how you don't add everything that the users asks for to the product. 

It needs to be comprehensive but still be readable. 

It needs to satisfy all stakeholders but still be brief. 

It needs to describe the problem and solution in detail but still be flexible to incorporate comments from various stakeholders. 

Moreover, 

It needs to be maintainable. 

It needs to be usable. 

It needs to be unambiguous. 

When I was new to product management, in the pre-PM-euphoria days, I couldn't find a good PRD template. So I created my own. When I found that it works really well, I put the "Sample Mobile Apps PRD" format on slideshare back in 2012 and it is still being viewed/downloaded by about 10 people every day since last 8 years. That's over 42k people from over 50 countries. This was more from my Business Analyst days, and I had evolved a new PRD format that I uploaded 2 years back and it is also being viewed by roughly 7 people every day. It covers most stuff that I figured other companies also try to follow. Also, it has a nice checklist for PMs. 




But I don't use any of those templates now. 



Because it is boring to follow the same format everytime. It's hard to find the template every time, copy it in a new doc and start filling it up. 

That's not how most documents get created anyway. If you are in anyway similar to orgs that I have worked with - a lot of documentation happens on a task/ticket management software like Jira. A lot of documents start as a list of items on spreadsheets (asks, feature ideas, whiteboard screenshots) and then more keeps getting added to it as discussions happen. So, if one ever gets to write a proper PRD, it's more likely for your own job satisfaction. Btw, IMHO that's not a bad reason to be writing PRDs. Most PRDs end up being short lived, unread and futile. 

And it's not just me, or my org. People around the world think PRDs must die

Bear with me, a few more moments.  

So why are we looking to templatise futility? 

If you look at various PRD formats from best product companies across the world now so easily available on the internet - you'd realise that not much has changed from what I created 8 years back. Everyone wants to keep the key elements like the Problem, the Solution, the Scope (in-scope, out-of-scope), the Success Metrics, and the Dependencies. Some also like to include the background research and roll out plans. So that's it, you put these things in whatever format and you should be able to get a very functional PRD for your use. 

Well we need a way to ensure we don't forget something important. The right word for such a thing is a checklist. 

Checklists v/s Templates 

With templates comes the fear/lethargy of maintaining the status quo. If every document is different – it should look different and focus on solving the problem instead of maintaining the so-called standard format. Templates are one of the last remnants of the industrial revolution era factory system. Auditors and Managers wanted one to stick to their ‘prescribed’ formats because it was easy for ‘them’ to monitor and review. But, that’s not what modern docs are for. They are used across various stakeholders - and every one tries to get what they need from it - sales guys are interested in dates, customer success want to know how it works, devs want to know what needs to be built, QA wants to know what they have to test. What we need is checklists and not templates. 

So, we've talked about PRD being a product, and that in most cases they are mishandled and so they've not being very effective. 

But, where is the world's simplest PRD template? 

It's coming, it's coming. 

The PRD Template

It is not a template, it's a checklist. It's not even a standard long list of checkboxes kinda checklist. It's a simple mnemonic that you'd be able to easily recall while creating your next document or Jira ticket. 

Why, Business, Success, Depends on, Being thorough. 

And you can read and remember it like "why business success depends on being thorough?" 

Easy? I told ya! 

How it helps is that you can apply it to the smallest of Jira tickets and largest of Epic documents that you create. 

This covers most essential elements of the PRD. Here's what each of the check means:

1. WHY - Start with a why. It makes sense to start every ticket, every doc by answering this question however briefly it may be. Why are we doing this? This is the place to describe "the exact problem" you are solving for and any analysis you may have done around it. Remember that this is a checklist and not a template - so you don't need to put a heading "WHY" in the documentation. The heading/title of this section could be anything relevant. But, we ensure that we have given enough context and described to the reader why we are doing this at all. The way I like to do it is describe something very briefly and then provide larger context - just the way I have done it in this blog post. 

E.g. Engagement of the app is low. User's are not able to discover the feature X on their own. Expected engagement for such apps is nX/user/week. 

Target: Even though I dread the term 'everyone' - this section is actually meant for all stakeholders. More than anyone this section is for you. This helps you start on the right note and then stay focused. However, make sure you word it in a way that most business stakeholders - especially, the customer success team, marketing team understand it well. 

2. BUSINESS - Last section was about the problem, this one is about the potential impact of the solution. We need to define what is the Business Impact of the feature/change that you have defined or are going to describe in the document. Order of this (or any other) section is not important. So here's where you discuss/define the current state and what future will bring. How many users will be impacted, and how much? There is a list of good products that did not make any money, and died. So, being ROI centric is super critical. The real difference between real CEO and the PM (aka CEO of the product etc.) is that PM needs to talk ROI to persuade the stakeholders on their POV - gut feel doesn't work. If PRD has a section on business feasibility, impact this checkpoint is clear.    

E.g. Higher engagement would lead to increase in DAU/MAU ratio which proportionately increase our chance to covert from free to paid version. Higher engagement is critical for increasing conversion. 

Target: This would appeal the most to your sales and marketing teams. More so, if they are approving budgets or gearing up a campaign around it. 

3. SUCCESS - There needs to be a section that talks about success metrics. How'd you know if the impact is achieved. How exactly would you measure it. Enough is said in the world about how to measure what matters, so I'd keep it short. Just do it. 

E.g. this feature should increase the engagement by 15% within 5 weeks of launch. The increase in revenue should be upwards of 3% as measured after 10 weeks of launch.  

Target: Your data analytics and marketing teams should appreciate you for this. This section also nudges you to ensure a roll-out plan and GTM that will help you achieve the numbers. However, this is also a section that asks you if you're not confident of meeting the success metrics, is it worth the effort? 

4. DEPENDS ON - What is this feature/fix/change request depending on? Which other modules, third parties, features, channels, version, upgrade, roll-out are involved. Is the dependency one way or two way? This is the section that you most easily miss out. Primary reason is that it's hard to gauge all dependencies of the feature/change via the limited exposure the PM may have. But you might need the developers, tech architects and QA to find some dependencies for you. That needs a low ego and a high patience level. So go the extra mile, identify all dependencies and list them down. Add specifications around what change is expected or what's possibly disruptive - it should act as a nudge for your QA team to test out your dependencies.  

E.g. This report presents data that depends on enabling the XYZ property which is disabled by default. E.g. Changing the format of the API may impact the way data is stored in the warehouse for billing at a later point.   

Target: QA and developers mostly, but in many cases it will help customer success teams prepare themselves better for the new roll out. 

5. BEING THOROUGH - Finally the section you've been itching for. Where is the solution you'd ask? Here it goes. So, this is usually what PMs won't miss except this is also where a lot slips through the cracks. Make sure you are thorough. You should assume that building the feature and testing it is going to be only as good as the PRD you write. Even if that's not true, assuming it helps.   

E.g. Should the filter be checked when you come to edit it?

E.g. Who's the sender, subject and signature of the email that needs to be sent. 

E.g. What should the error message exactly say? How does it guide the user to take appropriate action is this error occurs.  

Target: Developers mostly - Try your fiction writing skills to make sure they read it. QA teams and every other team who wants to try the functionality out all by themselves would like it too. 

Parting thoughts

Let's revise why this is more useful than a template. 

  • Easy to remember and follow, easy to make jokes around. If it ain't easy to make jokes around a process/policy, it is forgotten and hence not followed. 
  • Forces you to focus on the right things and document them - thereby creating a better, more useful reference for yourself and the team. 
  • This works on all docs - big and small, elaborate, and succinct. My rule of thumb - anything more than 4 hours of effort should follow the entire checklist. The smallest spec you can write, while following the entire checklist will be 5-6 lines. I am sure you won't disagree with writing that much for a spec. 
  • Works for self-review, or review of specs by a peer/senior. Do you have a spec review process?
  • Works for keeping most stakeholders on the same page. It has elements for everyone. In fact if you have specific comments for a team: you should mention that clearly. 
  • It isn't boring like a template and comes with the flexibility to add your own creativity. All great PMs always improvise. Like you would have already done with Scrum/Agile, feel free to internalize this and create your own version of it. There are certain tweaks of this mnemonic that you can alternatively use. E.g. Why business success depends on the roll-out plan being through, OR Why business success depends on GTM being thorough, etc.  
E.g. A quick 4 page document that follows the checklist


E.g. A Jira Ticket (no attached doc) also follows it

I am sure you'd go back and start reviewing your docs and start filling the gaps. Let me know in the comments if this was helpful or if you need help with it. 


----------

Leave a comment for the author. It makes his day. 

PM is a Double Agent

Most Popular on this blog