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?

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?

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.

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.

#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

Product Thinking: Be a Problemist!

People don't buy a Rolex watch to manage their time better. 

What else is a watch supposed to do? In this case, clearly, it's solving a very different kind of problem. Knowing what kind of problem you are solving for your customer, or through your product (whichever comes more naturally to you) unveils the way to a more effective product roadmap. Painkillers, Vitamins, and Candies all make million-dollar businesses - only if you know what you are creating and market it that way. If you positon a painkiller like a vitamin it won't sell. If you position a vitamin as a painkiller, you might get sued. 

Product Management is all about finding real problems of real users who are really looking for solutions. So, in this post, I've tried articulating a framework of doing a problem analysis instead of thinking of a solution. I have extensively talked about this framework in my talks and workshops and it works wonderfully well for a lot of people.  

Remember that the problems set is a subset of the user's Needs and Want. 

As a PM, you should be spending significant time in exploring the details and finding the root cause of those problems. In fact, while I just defined this for PMs, this is completely true for all startup founders. You must be solving for a pertinent problem of your existing/prospective user base. 

I am not suggesting that you are not responsible for solutions. I am saying that solution is not what you should worry about until the problem is well understood. Solutions will either be obvious or will reduce down to some logical or mathematical problem once you've done a good job of analyzing the problem. 

FAQ: What if I am not really solving a problem? 

Feel free to call your work an Art. 

Harsh? Truth. 

If you aren't solving someone's problem, you've no reason to believe they'd pay you. Even in most narrow context - if your shiny new feature or design or CSS change is not going to solve a real pain point of the user, you are putting money down the drain. Btw, if you think that Facebook, Tiktok, and Netflix of the world aren't solving a real problem, think again. 

FAQ: What if it's a value add (versus solution to a problem)? 

Well, if you aren't concerned about clear ROI, then anything is fine. Typically the "Value add" products/features make a limited impact for a small set of users, mostly for a limited time. A harsh truth, again. But, if that's what it is, accept it and you'd still do well. There are other problems as highlighted in the illustration below.  

Now that we've seen some deep dive into why focusing on "Problem" is critical let's see how we can deal with it. It looks like a step by step process, but it will quickly become a mental model once after trying some steps for some of the real situations you come across. 

 

1. Define the problem

Recently a startup founder was seeking mentoring and he pitched to me a digital business card organizer and I asked him what is the problem he is solving. He started talking about the solution. I stopped him and asked what exactly is the problem he was solving. This time he described it well - the problem he was trying to solve was that people miss out on their network because their network is not well organized. And then, at the earliest opportunity, he switched back to describing the solution again. He wasn't convinced that I am NOT his customer. He kept asking me to imagine situations I have never gotten in to and use cases I've never had. 

If you enjoyed the story this far, let me tell you that this is true for roughly 6 of the 10 founders I meet or half the PMs I've interviewed. A problem defined as a solution is not the right problem to solve.  

It's hard, really hard, to define problems while completely ignoring the solution. But, every effort in the right direction helps. 

If you have a feature idea or a solution ask what problem is it suppose to solve? Whose problem it actually is? 

Ask who's the "ideal" customer? and if the answer sounds like "Everyone", it is very likely a wrong answer.  

Quick check: In most cases, if you've defined the problem such that there is only one obvious solution, your definition needs improvement. Problems are usually multi-causal and can be solved in many different ways. 

2. Categorize the problem

This applies to any product and any startup. If you are going to remember any piece from this big essay, then remember just this part. Categorizing a problem gives you the approach to solve it, but more important than that, it also tells you whether you should be solving this problem right now or park it for later. If you have been a product manager long enough, you'd have heard about "Ruthless Prioritisation". This is where it happens. 

You need to categorize the problem into one of the following categories. 

Latent - User has a problem but the user doesn't even know they have a problem. How's that possible you think? Well, people didn't know they need to brush their teeth twice a day just 70 years ago. They didn't know in India they need a RO (water purifier) 20 years ago. Like they don't know they need an air purifier in 2020, wait for the next 5-6 years and see how it becomes a 'need'. A lot of things from personal undiscovered health ailments (mental disorder, diabetes) to your vehicle-is-eating-more-fuel-than-required to global climate change fall under the latent problems. People at large don't know they have this problem and if you are going to create a solution for that problem, they wouldn't buy it. 

You'd need persistent educational/marketing efforts, for years, to turn a latent need into a want.    

Passive - Users know they have a problem but they are not interested in solving it. This seems worse than the latent problem, but it is not. Now that the user already knows they have a problem, you have a higher chance of converting them sooner. But if the user is not solving for it yet, you know that the problem is not big enough for them yet. Insurance, Anti-virus, Inbox-zero, Cybersecurity products, Pay later, Accessories like a Health band typically fall under this category. 

Bundling your product with something people buy more frequently works great for products in this category. Also sells well if it is part of a new 'trend'.   

Active - Users know they have a problem and are actively looking for a solution. However, it's not a burning issue. It's a leaky tap and not a pipe burst. So they'd think more, they'd tend to care a lot about the cost, quality(UI/Feedback/Rating), their processes, competitive analysis, etc. The sales cycles are long and you need to keep retargeting your ads to the prospective leads. A book-keeping saas for SMB, a Math tuition app for a 10 yo, a Compliance/Auditing tool for Finance Department, an advanced SEO optimizer are some products that typically fall under this category.

Active follow-ups, retargeting ads, discounts, more value-add offer work for these products.      

Urgent - User's ass is on fire and they know it. If you are making a product that she needs, and wants and is a burning problem for her, just make sure you're there at the right time to take the money. In most cases the big urgent problems of the market are solved already, so you might find a lot of comparable competition. If you don't have the distribution, being 10x better is the key. Lending products, Travel booking, Communication apps, etc. fall under this category.     

Perceived - These are imaginary problems. They do not exist, but like ghosts, some people are convinced of their existence. Solution - VooDoo. It's more about communication, presenting facts, building relationships, tweaking the UI, changing the error message, standing on one leg, or whatever it takes to change their false perception. Could be some placebo or add-ons in the product, but most of the time, solutions will lie outside of the product. Imaginary problems need imaginative solutions.  

A few things to note:

1. Markets are dynamic - people and their problems, their needs, and their want are changing. So, while you start with a latent problem it "may" become urgent in a few years. 

  

2. Things like a global pandemic or demonetization can turn the situation VERY quickly. The same problems can go from latent to urgent almost overnight. Of course, you can't bet on these black swans. 

3. Reframe the problem 

Here's a brilliant article that discusses reframing problems at length. It gives examples of how a slow elevator problem can actually be reframed as "wait time is boring" and can be solved by installing a mirror in the elevator. How a dog adoption problem in the US was actually a poverty problem. 

The existing framing may not necessarily be wrong, this step is more about finding a better problem to solve. 

Here's some fun from Reddit, that says adding a faster spinner solved the perceived problem of a slow website. 

 

Here are a few quick questions that you can try to answer, wrt the problem at hand. Particularly, for a feature ask it can help reframe the problem:

• Is it an incentive problem? - They have no reason to do the right thing. If I can guide the delivery boy who speaks the local language, I have no incentive to learn how to locate the delivery address on the map correctly. 
• An expectations problem? - They didn't expect they'd need to do this. They didn't expect to fill a long-form. Where is all the artificial intelligence?
• An attitude problem? - They just don't want to do this (no good reason). Inertia is real, no one wants to change their behavior. 
• Perception problem? - New things have historically never worked, so they don't want to try. 
• Misinformation problem? - They are convinced, other similar products behave differently. Victims of competition's sales pitch or content marketing. Other products have that one feature and are obviously faster/cheaper/simpler. 
• Is the problem stemming from another solution? - Some other feature/constraint in your product makes them believe that the new problem has to have a similar solution. 

A solution can lead to a new problem

I wanted to drop some hints on how to solve each of these problems, but the post is about being a problemist. Trust me, focus on reframing the problem, and the solution will appear. 

4. Measure the problem 

How many users are affected?

It's ok to start by asking around, estimating, back-of-the-envelope calculation so that you can take a quick call on how to proceed further. If your product is instrumented, you should be able to find an actual number of users facing this problem. Even if the product is not instrumented, if there are active users, you should be able to dig data and find some number. If it's a new product just take guess whether this will be useful for 80% users or 20% of them. Important is to have a number and make sure it is written down in the documentation you do - PRD/Jira ticket/Whatever.  

How much are those users affected?

Can the impact be quantified? How much cost or time or life does it save for the users? 

Another good proxy is self-discoverability. How likely is the user to discover the change/feature by themselves and use it? If it is very likely, then we are talking about high impact.

5. Ignore their solution

The #1 reason why people have to change their roadmap too often is because they base it on what customer asks them to build. And when they go to the next customer, they'd ask something else. 

It's hard to be blunt to the customer or ignore their solution and ask them more about the problem. In their mind, it is already fixed by the solution they suggested. So listen to them first. Paraphrase and in your narration, you may induce items from your curiosity that forces them to think as well. Then ask questions and do a deeper analysis of their problem - need - want. 

If you leave it to them, they'd color the Taj. 

However, reaching a granular level is secondary. I see most people struggle to even rephrase the user need/problem as a "problem" instead of jumping to the solution. Recently, I spoke to a stakeholder that works closely with the customer and asked him about the customer's pain. He described that customer wants an attendance management system for their drivers. I asked him what is the "problem" they are trying to solve? He reiterated, that the client needs an attendance management system. He was partially surprised, what about a simple "attendance management" bit I could not be getting. Another stakeholder suggested that we have tried some basic solutions in the past and no one uses it. So now the problem apparently is to create an "attendance management system" that is "usable". I spoke to the customer directly. 

Hint - A problem defined in terms of a solution is a wrong problem to solve. 

Here's more detail, "The customer was unable to track the presence of the driver within the campus for the prescribed duty hours, because of which they are unable to decide on prorating the remuneration for the driver. The client estimates that this leads to delays in payments and even overpayments of about 10%. As of now, the client depends on manual records and driver's trip records. There could be exceptions, in which case, the driver may not be working but still getting paid for the day." 

When I dived deeper into conversation with the customer I found that in most cases where they might make a mistake of capturing fewer trips for a driver, the driver will reach out to provide enough evidence and get it sorted. However, if they are paying extra - no one complains.  

So, as I spoke to the customer, I found that there is just one distinct problem. The question customer struggles to answer every month is "Am I overpaying?"

All I wanted to know was that the client fears he is overpaying. That's the REAL problem that needs to be solved. 

My solution, a simple report that lists all the drivers who should not be paid the full package. I had everything I needed to create the report so the effort was about 20x smaller than creating a new system. The turn around time was quick and the solution was sufficient to solve the problem. 

So, the quick mantra is just to ignore their solution. Follow all the earlier steps and figure a solution from the ground up. It will be fun and will save a lot of time and money, more importantly, the disappointment of creating something that no one ends up using. 

6. Devise your solution

Finally, now that you've earned a doctorate on the problem, the solution would be clear. More than the solution the problem analysis gives you a clue about how to approach the solution in the right way. How to drag the solution so that it lies somewhere in the problem-need-want area. Many times, you would realize that the problem is not alone, it is a bunch. And there could be more than one solution to solve it. A lot has been written on prioritizing the different solutions and building them so I'd skip that part. However, here are some useful tips for the solutioning process.

   

- Document it - Write it down. What if you die tomorrow? Leave the world a better place. Make sure you define the problem analysis in the document (at least briefly). Begin your documentation with a problem analysis - whether it is a PRD or quick Jira ticket or a handwritten note. It's not an afterthought, just begin with it. 

- Prototype it - Big change? Always prototype it with a hi-res flowing prototype. Notice how the first prototype and the third one are shockingly different. 

 - MVP it - If you have a risky assumption about the problem or the client or the solution - do an MVP. Test your assumption. There is a lot written on MVP so I'd not repeat it. Just remember this that if your MVP is not testing the riskiest assumption it is not an MVP. I love to use spreadsheets and no-code tools for MVPs.  

 

- Build the solution -  Once you have gone through the earlier steps, or have low stakes or absolute clarity on what needs to be built or it's a small change. Just build the solution that appeared from the problem analysis. 

7. Measure the solution

I'd not call it complete if you don't measure the solution against your problem. Achieve the problem-solution fit before you go for the product-market fit. Solving the wrong problem ends up measuring the wrong metric. Measuring the right metric is extremely important. It's not about how many features you build or how fast you build them, it's about how quickly are you able to achieve the business outcome. 

When you chase the wrong problem or wrong metric.

Once you try to follow this approach with strong intent, after a couple times, I assure you it takes lesser time to do the problem analysis than you took to read this post. 

Be a problemist! It's goooooood. 

Long ago in a PM job interview, the interviewer asked me if I was part of the problems team or the solutions team. Frankly, I did not even understand the question then.

But then over the years, I've realized what it meant. It's now one of my most frequently used phrases when talking to my team members - "Remember, we are the 'problems' team".  

--

If you reached this far, you are quite a reader. Please leave some comments for the author. 

Customer Success (not PM) is the role of the Future

Source: News Examiner

I feel that Customer Success teams have an opportunity to deal with humans where tech/products can't. As more people realize that how much ever user-centricity they build in the product, it's not going to engage people like people do - more folks will look for the right customer success guy.

Particularly in enterprise products, the stakeholder chain is large and includes user, customer, economic buyer, influencer, recommender, and in most cases saboteur. The stakeholder chain is also dynamic - people move, policies change. A technology product is far too passive to respond to the dynamism in real-time. It needs ultra-smart people to keep at the pulse of the relationship.

In fact, both CS and PM have a lot in common. Both roles have a very fluid definition across organizations, both require a very wide range of skills (more wide than deep), and are expected to fill a lot of white space. Product management has matured a bit in terms of definition, frameworks, and tools. It has gathered way more attention and popularity then it should and Customer Success apparently still hasn't caught the fancy of the right people. I believe as startups mature in their thinking and Customer Success matures as a field, this will be a very sought after role.

In many ways, CS is the CEO of the Client relationship (that limited business). They architect it, nurture it, rally resources (including product/technology/human), make decisions, tell stories, negotiate, persuade across the internal and external stakeholder chain - all with an intent to make sure the business improves. They are more likely managing P&L in most organizations and not the PMs. And I've seen founders wonder how they can make PMs own P&L, or should they even. It probably looks like the right approach but it doesn't seem natural to get this rolling.

It's because often product guys should do what they should - manage the product. Product success is definitely their responsibility, but, business success is way more than the right product. Business is about building trust and managing it. Customer Success very nicely placed between product and sales - just how product roles nicely sit between tech and sales.

If you are into CS or getting a chance to get into it - grab it. The future will need you more.

How to "Get Shit Done" as a Product manager

A PMs guide to Hustling

Everyone says that a PM needs to hustle, make it happen, get shit done. No one tells how?

Here's a quick framework based on the Chanakya-Niti. If you do not have the context of Chanakya, you can call it RRRTR.

Chanakya's Niti (Policy) says:

You can get something done by Saam (Request)- Daam (Reward)- Dand (Reprimand)- Bhed(Threaten) to be applied in that order. I've added a Repeat loop to it, Chanakya might have considered the same as part of Saam (Request), but I wanted to be more apparent.

A lot of times we face Opponents in our work. Bear in mind that the "Opponent" is not an enemy, it's a temporary state where someone is resisting the change and we are pushing for. It could be a friend, relative, even our kids. So in the entire text wherever I say opponent or adversary - you don't have to take your swords out.

Also, when I say office Politics I don't mean it in a devilish, dirty way. There are hierarchies in flat hierarchical structures. There are people - old and new, there are designations - higher and lower. There are personalities - strong and weak (in terms of influence). Here's what politics means by the Wikipedia definition:

And there are, in every significantly large organization, some politics that stems from its history, culture and people. Heck it takes only two people to have a power struggle, it is definitely there in small orgs - it can only be less or more apparent in comparison with others. It cannot, "NOT" exist.

So, now that I've defined the two words I am going to be using, I imagine you've lowered your guards and swords and are open to see things in a different light.

Here's how I've found the Chanakya's principles handy in navigating through the office politics and getting shit done by all people - Big and Small.

Disclaimer: I am no politician or expert. I am just trying to articulate what has worked for me, and many good managers might already be doing it instinctively.

Request (Saama)
One can always get most of your tasks done, even by your opponents if you make a polite request with a reason. When I am stuck I first try to cajole directly. A request with a strong reason works much better than just making a request. E.g. "I need this by today because...". However, in an office environment where you have many stakeholders to manage, it pays to have good relations with a lot of people. I'd regularly meet people over lunch/coffee, engage in banters, and also uprise them about the latest product stuff we are on to.

It takes a while to actually understand their pain points, challenges, and motivations. It requires a lot of careful listening. But, once I know these it becomes so much easier to collaborate with them. The focus has to be on them and their way of working. E.g. Some people are good with emails, some are good with calls - they find it hard to track emails. Whatever nasty email I dropped them, they will not pay any heed to my request. But, I later realized that I can simply make a call and get shit done instead of getting hung on my belief that "Email is THE professional communication medium". Little things like this help in engaging with people in the right way.

It always helps to ask if the person you are requesting to, is the right person for the job. Particularly in Asia, people have a hard time saying no and can end up wasting your time by not telling you that they aren't supposed to be doing this. When in doubt I ask who can do "this".  When I am asking the right person I get a volunteer. When I ask the wrong person, I get a referral. 

In addition, what has also worked is influencing through a peer. Sometimes work gets done better and faster because their friend asked them to do it instead of a random leader of another group.

Reward (Daama)
Daam literally means Price - indicating paying the price. It can also be taken as Bribing. In our context, you obviously won't be offering money to people under the table. But, sometimes you literally do - like a pizza to a team working late. Like negotiating a comp-off for a person putting in a weekend for your cause, providing a bit of leniency in work hours etc. It goes a long way in building a personal connection for a professional cause.

This has limitations, as you may not be able to do that to people who do not report to you. But, you can loop in their manager in an appreciation email. You can potentially recommend them for an internal award.

Exchange favors of other kinds. Sometimes a promise of help is also very effective - imagined gain is higher than the gain itself.

Threaten (Bheda)
Imagined fear is a very effective tool. Sometimes the threat of an escalation works better than escalation itself. Threats can be direct - "I'd have to escalate" or subtle - "I'd see if I can find someone who can do this."

You may be able to outnumber the opponent in certain cases by getting either more people pitching in your favor or more people against your opponent. Lobbying with influencers works the magic.

Who you know is more powerful than what you know. And what you know about who you know, is even more powerful. Bheda literally means distinction or division. It also means secrets - alluding to blackmail. Again, this may sound dark, but, hustling doesn't see boundaries. Also, how you connect with people and how you present your case is the difference between building and ruining relationships. E.g. Once a team manager was acting too bureaucratic, wanted me to follow a process that I had no time for. I had to jokingly add a small reminder of how a mistake he did in spite of me following the required process, had cost us some pain and rework. I did not have to tell him that he owes me a favor. Opponent's vulnerability is your power. Again just taking this out of context, it sounds plain evil. The team manager in context is a workplace-friend, we've spent a lot of time in banters and coffee machine conversations. He just gets too many urgent requests, so I have to convince him about the severity.

Reprimand (Danda)
When nothing works you have to take the unpleasant route. There is a well-known rule that one should appreciate in public and reprimand in private. One should keep that in mind. The best form of reprimand starts with the right questions and a curious tone (not a suspecting one). I focus on asking Why and listening attentively to justifications. It is important to be conscious about this, otherwise, you may not be able to have complete control over your communication.

Sometimes you may not be in a position to reprimand (e.g. if they do not report to you). You have to escalate and outnumber your opponent. When everything else fails you may have to coordinate with someone who can command action. Again, what you know is less important than who you know.

Repeat 
Persistence matters. The last time you made the request you might have found her at the wrong time and she denied without much intent. Or, maybe she wanted to take up your request but forgot. Or, she still wants to do it but she has scheduled it for later. How will you find out until you follow up? "But, I shouldn't need to follow up" is a flawed argument in most of the practical situations. Sanjay Swami (VC @ PrimeVP) once mentioned his mantra for startups - you eff up if you don't F'up (You F*** up if you don't Follow-up). It's an important mantra for all hustlers.


So here it is then, my strategy for hustling. 90% of my tasks gets done with Request and Repeat. But then, there is a nice line in a Hindi poem by revolutionary poet Ramdhari Singh 'Dinkar':

It translates to  -

"Tolerance, forgiveness, mercy is worshiped only when there is an established power behind it."

It's not the tolerance of the meek that people talk about, it is tolerance of the powerful that is celebrated. So, while Request and persistence work nicely, they mostly work when one has established the power to use "other means" of getting things done.


---
If you liked what you read, please leave some comments for the author.