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. 

Monday, September 21, 2020

What is CRED's business model?



Trust is so underrated. 

The secret to a better life, a better economy, and a better society is high trust in the humans around you. Cred wants to become a community of verified high-income individuals who trust each other. The business part will have all the key ingredients of any modern internet business, but there are parts that are still evolving.  

So, it is Fintech?


Yes and No. Payment/repayment is an entry point. You got to start somewhere. It's fintech today, ed-tech tomorrow, x-tech someday. 
Cred is largely horizontal - so limiting it to a vertical is an exercise in futility. 


Horizontal is what? explain.


Here you go.


It is a Social Network


While your CC payments or rent happened to be a starting use case. Most people are here because they think it is a privilege to be here. There is a velvet rope effect at play. If you don't have a high enough credit score, you're NOT allowed. It's a network for a niche community. They pay together, and they play together. 


But you said social network - can I post a selfie? 
Have patience, it would come. Less like Instagram, more like Bumble. 


Dating site? 
No that's not what I mean. 


Lunchclub then?
Not that either, but it would have elements of both. 

You're confusing me. 
Wait, jumping to conclusions is not our national sport. It's a horizontal and like every universe it keeps expanding. Wait for it to take its own form and shape, don't bucket it yet.   

It is a Game


Just like you keep opening the refrigerator when you are bored, you know there is nothing new in it, but you still check if something can be worked out. Also like a Farmville that hooked millions of people, the cred game also needs you to keep checking regularly otherwise your crops will wither. The game loop is not limited to one game or challenge on the app. The game is larger - finding something to do is the game. Once you open it - you've to look for what interesting stuff can you do, and then do that, find resistance, burn some coins, make a purchase/referral, unlock a new stage, find more things to do, and so on in a loop. A mundane task like Payment has been gamified to get you started. Rewarding someone on top of extremely low margin payments cannot be a real business for any volume of transactions. Think of it as a sport, the payment is just an entry point (a participation ticket). The real strategy is just to make you play the game. 

It's a marketplace


There are only 3 ways you monetize an app - Ads, Transactions (direct/affiliate), Subscription. Again it's not a typical e-commerce market place where you find everything, it's a premium Showroom of curated stuff. A premium Expo of sorts. If Flipkart is Big Bazaar, cred is UB City Mall (Sorry only Bengalurians will get it). 


So, what can you buy/sell? 
Anything and everything that you can, to be in the game of trust. Whether it is a subscription or a perfume or a course, micro-insurance or movie tickets, it's not regular, not essential for life, but high-quality stuff that only cred players can buy. It's not just material things or services - you can potentially Shopify yourself here. 

SHOPIFY YOURSELF? You keep dropping these word bombs. So, it is three things?
No. No. It's not three things. 

It is just 3 ways of looking at the same thing. It's 3 UI for the same backend. You can take any one of them and put the other two as an integral part of the same. You can see it as a game like PUBG that needs a community and marketplace to sustain. Or you can see it as a Social Network like Facebook that has games and a marketplace. Or finally, a community-driven marketplace like Meesho or Etsy where games are only for engagement.

It doesn't look like any of these 3, why is it masquerading as something else?
Well, if you see closely all other businesses that I talked about have the same 3 elements and they have hooked on to one front-end identity. Cred's front-end identity is still evolving. And it's critical, the new identity for a completely new type of community should evolve with time. You can't just label community culture and create it - it happens, steadily and strategically with people.

Future


So now that Cred has a following it just needs to focus on making the high-trust community that we talked about earlier. 

What is the "trust" thing that you keep harping about? 
Trust is either a democratic opinion or an intuition.

What? You are irritatingly brief. Does that even mean something?
Yeah, read that again and think about it. 

<pause> 

So? 
So essentially most of Cred's focus will be on establishing trust and solving your trust issues. If that means counseling, so be it.

Wait! You mean healthcare?
I said no verticals. I am acrophobic.

Okay. I am listening.
Ok.

The market place will keep expanding such that you start looking at cred validation for all your costly choices. Your kid's school, your second car, your life-partner, your dream home or next holiday destination. It looks like an overwhelming number of things in one sentence. But life is long and technology follows Moore's law. Also, you don't cred for shopping, you cred for fun.

The game will continue to evolve to encourage higher participation. The next level is to get the next set of people that may not have credit scores but the existing cred-ible people trust. The rules of entry will change and instead of credit score, a native cred score will be more valuable (not just within the game). Lending money will be just another parallel stage in the game - one line item in some corner. The currency of this game is trust, you'd bet trust, trade trust, exchange trust, gain/lose trust. Those two words - trust and currency used together often lead people to crypto.

Did you say crypto?
Yes, but wait. Of course, it's illegal right now, but, the one lesson 2020 has taught us is that anything is possible. Also, that's not the point, you don't come here to play, it's a socializing place. Right?

Yeah, I know what you did there. Leading to social networking. Huh!
The social network would encourage the formation of communities within the larger umbrella.

How?
Multiplayer Games, discussion forums, hobbies, travel, Q&A, chat, local search - a lot of possibilities. You may see some of them, a hybrid of some of them, or all of them in a well-integrated package in the future. There are N different use cases - from cred-tube, credagram, credinder, cred-fit, credoura to cred-versity, you'd see everything. Some experiments will be lost in the oblivion, some others will stay and become part of the definition.

So would I be taking selfies?
I understand your self-expression is very important for social networking. But it doesn't always need to be in form of selfies right? Besides, you are here for some thumb exercise and window shopping. Right?

Right. You're in-cred-ible.
Not really, I am a Cred user.

Whatever.
See creating Trust at scale is not simple. It's almost like building the whole country again.

What? Okay, you'd need Product-Jio fit for that.
Well, that's a discussion for another day. When it comes to Jio, I can't divulge much information. 



--- --- -- - -- --- - -- -- -- - -- - -- - -- -- -- -- -- -- -- - - -- -- --- -- - -- - - - --- - -- - - -- -- -
This is an imaginary beer conversation of a teetotaler product guy. An opinion piece. No relation with any business model living or dead. Any resemblance to future plans of Cred is purely coincidental. If there is Sci-Fi for science fiction, why is there no #Biz-Fi for business fiction?

Wednesday, September 9, 2020

Are you growing as a PM?

Once in a while, I get questions about what should we expect from the Product Managers. Ideally, PMs are empowered to define their work and set expectations from them. While "seeking" clarity is definitely important for everyone, the Product Managers at any level is actually responsible for "bringing" clarity and value.

So while you set on your mission to bring clarity and value in whatever way you can, here's a list of things that you are also expected to do. You can use them to set expectations with your PM teams and also self evaluate your contribution and growth as a PM in any organization. 


1. Manage Outcomes: Focus on achieving the intended outcome expected from a product/feature. Don't stop at building features, ensure quality, adoption, and proper usage or whatever is the expected outcome. Move the metrics, or change the meters.


2. Deal with chaos: Understand the need of the hour and bring clarity for the team, be flexible, expect requirements/market to change, and plan for it. Constantly course-correct your understanding and estimations of priority, impact, and effort. Set up PM processes to help you achieve this. 


3. Document everything: Write clear, detailed, readable, unambiguous specs. Document your backlog, roadmap, sprints, and key decisions. Includes release notes, user guides, demos, sales presentations.


4. Update up: Inform and assist the reporting manager in carrying out their work, it may mean creating a list for this and a list for that. It also means being on top of all assigned tasks and completing them in the expected time frame, and raising red/orange flags about things that need reporting manager's attention.


5. Manage the development process: Run sprints, actively monitor progress, and constantly unblock the design, marketing, and engineering teams, take steps to ensure they are motivated and able to perform their best.


6. Manage peers: Keep all stakeholders informed and engaged. Be aware of their needs and set their expectations correctly. It can get overwhelming at times, but, being data-oriented, clear, and positive is the key.


7. Improve status quo: Bring in new ideas, try new tools/processes, unearth new problems, and better ways to solve them. Make the product/culture/company and world better for yourself and everyone.


Periodically, you can go through this checklist and assess if you are doing 5-star work in all these things and have demonstrable evidence of your contribution. If not, you are not growing in all the areas that you potentially can. So, get going with it. 

Thoughts?

Sunday, August 23, 2020

Stop firefighting PMs: Cheers to Processes!

Simon Sinek says we should “Start with a Why”. So let me start this essay as well by answering why should we even have one on this topic. I have seen many orgs end up making huge PM teams and lean heavily on Engineering processes but not enough PM process to ensure PMs are doing well.

While everyone is focused on productivity and quality of Engineering, but the processes for quality PMing is negligible or non-existent.

Image for post
What’s your PM Process (not development process)?

Here is why a PM-Process is extremely critical:

  • We’re always Firefighting: PMs lose focus on business objectives and find it difficult to prioritize correctly — leads to more firefighting, “busy” work, burnout. This also leads to building things no one really wants — or more surprisingly features that they say they want but still don’t adopt. You can’t really be creative when your ass is on fire.
  • Loss of Engg Effort and Productivity: PMs keep hopping from building one feature to another instead of achieving the outcome — this leads to customer frustration, loss of engineering bandwidth, worst of all loss of motivation. UX Coach Jared Spool has some amazing insights on the cost of frustration.
  • Complex product: PMs work on islands, they focus on their specific areas/modules/features instead of the user’s whole experience. That makes them look for unstable hacks, workarounds, or complicated features that end up creating a complex, less maintainable product and a never-ending Tech Backlog.

How did we end up here?

If one or more problems look relevant to you, do spare a thought on how did that even happen. I’d ask another why. Why did this happen:

  • No set process for PMs —you are mostly making ends meet, building one feature and hopping on to the next feature
  • No templates for requirement gathering, design, documentation (PRD/Jira ticket), release notes or user manuals, or if there were templates in the beginning — no one knows now.
  • No quality check on PMing — no formal channel to gather PM’s efficacy. Tracking it back from Product failure is too little, too late.
  • Frequent change of direction — while sometimes this is circumstantial, short-term planning and sticking to the plan is critical for efficiency, keeping up motivation, and avoiding burn. It could be you or HiPPO.
Image for post
#burn

So, what do we do?

So here are some solutions that will, over a period of time, help us get rid of all these problems.

  1. Articulating your PM Values and Principles
  2. Creating/Following PM Processes

PM Values and Principles

PM Processes will change based on your maturity and need, but your PM values and principles would most likely remain unchanged for a very long time.

Here are some product management values for starters:

Empathy: Being Empathetic creates trust and helps the PM lead without authority. Also, helps PMs build the right thing, reduce ambiguity, avoid tussles, boost morale. It also involves creating readable documents, responding quickly to emails, and creating delightful user experiences.

Curious: Being curious is a precursor to being innovative. Probe the customer, probe the stakeholder, probe the market, probe the existing data. Is there a better way to design it, do it, market it, sell it?

High-Agency: High Agency person looks to bend reality to their will(Copied from this awesome twitter thread). They either find a way or make a way for themselves. Get things done.

ROI Focused: As discussed earlier that we should start with a Why. Focus on how much value the user or organization will be getting because of this product/ feature/ change/ tweak leads to faster/better decision making. Ask: Is it worth the effort that we are going to put in?

Clarity: The world is messy and getting messier. It’s important to constantly reduce entropy by creating reasonable plans and sticking to them. Document unambiguously, use simple and clear language with visuals, go the extra mile in teaching all stakeholders the value, and working of what’s been built.

PM Principles

The guiding principles are derived from the values, that help us with two distinct things

  1. Put values into practice
  2. The principles help us create and improve different PM processes so that we can solve the problems identified at the beginning of this essay

Here we go the 8-Fold Path:

  1. KYC (Know your customer): Distance relationships don’t work. The longer we stay away from clients the higher the chance of us losing control over priorities. Dedicate time periodically to talk to a client/potential client — internal or external. Additionally, attend a sales call or a client demo. In some projects you’d easily get a chance, in others, you will have to make efforts to talk to your clients. It’s not a one-time thing, it’s a continuous activity. #empathy
  2. Think Problems, not solutions: The magic is in defining problems such that finding the solution is reduced to a logical/mathematical problem. #roi-focus
  3. Show, Not Tell: Be as visual as it gets. Add screenshots where you can, A high fidelity wireframe is better than a hand-drawn one is better than nothing. Write copy, not lorem ipsum, the copy is design. #empathy #clarity
  4. Own the Emotion: A product is not just getting the correct feature/ functionality — it’s getting the correct emotion. Measure emotion, not just numbers. Emotion comes from the overall experience — that includes the full suite of features, products that the client uses. Keep an eye on the complete experience not just our specific feature/product. #empathy #high-agency
  5. KYP (Know your product): Eat your own dog food. Invent ways by which you, your team, or some internal team is able to use the feature and give brutally honest feedback. If you can’t use it no one will. #empathy
  6. Think Outcomes, not Output: If you aren’t measuring, you are not improving. Ask about business goals for every decision, call out when the goals are unclear. Building the feature is just a 20% job done. If they aren’t using it, our effort is wasted. Repeat: We measure emotion, not just numbers. #roi-focus
  7. Ask: Ask what’s new (and what’s stale). Prod the clients, the stakeholders, the engineers, the data. Question the current state, and ask if there is a better way. #curious
  8. Write it down: Life is short, memory is fleeting. Write down your thoughts, specs, sprint themes, roadmaps, plans, and the reasons for making those decisions or making that plan. Document key decisions and thoughts in a shareable artifact and share it with all stakeholders. #clarity #high-agency

PM Processes

Success is a process. This 8-fold path can help you build PM processes based on your context, maturity, burning need.

Processes will be contextual, temporary and you should evolve them with your team, not in your cabin.

I am not describing the processes I’ve built, because they are contextual and suited very specifically to the orgs I’ve worked with. However, if you absorb and articulate your PM Values and Principles they’d surely guide you to create the right processes.

For example,

  • the Think Problem, not solution principle can lead you to create a documentation template or a checklist(better) where all your docs start with problem analysis first. And you may need a temporary process to foster this documentation discipline among all team members.
  • Own the emotion may suggest a need for regular communication and coordination among different product peers/teams. A Bi-weekly demo/standup?
  • KYC/KYP can suggest adding a step in your regular documentation/release process. If it ain’t dogfooded it ain’t released.

If you have any issue in creating your Values/ Principles/ Processes I can help. When you focus on the PM’s problem you are trying to solve, articulate your PM Values and Principles — the process part will be easy.

Thoughts? Questions?

--

Originally appeared on medium

PM is a Double Agent

Most Popular on this blog