Dinker Charak's Blog, page 6

Ignoring Employee Experience (EX): A $900M Lesson for Enterprises

Background

The good thing about buzzwords is that they make a concept accessible to many. Many Product Management buzzwords were popularized by Silicon Valley startups. A few of these buzzwords were quickly picked by enterprises too. Especially by a bold & courageous executive leading transformation within an enterprise.

One such buzzword is Customer Experience (CX). It has helped enterprises cut through mountainous hierarchies, fragmented decision-making, and “approvals’ driven buerocracy. Customer Experience brought to table an Occam’s Razor variant:

If it improves a customer experience, it is the right thing to do.

So What is My Problem?

The bad thing about a buzzword like ‘Customer Experience’ is that it has turned an organization’s focus into a zero-sum game.

The biggest loser in this zero-sum game of Customer Experience is Employee Experience. Above that, the further an employee is from a Customer’s touch-point, the worse is the experience.

This is also evident from budgets assigned to the improvement of Customer Experience.

“Organizations have matured in their understanding of the business outcomes that CX delivers,” said Augie Ray, VP analyst, Gartner for Marketers. “As a result, the budget outlook is expected to grow to match. This raises the stakes for CX leaders to select metrics that demonstrate impact and prove the value of CX to business results.”

“Gartner Says 74% of Customer Experience Leaders Expect Budgets to Rise in 2020”. Press Release. January 15, 2020

A Case in Point: The $900m Gaffe

Almost all of us have heard about the $900m transfer from a large bank to a customer and then their struggle to get that money back.

For those who are not aware, this excerpt from a Bloomberg.com article is a great summary:

Last August, Citigroup Inc. wired $900 million to some hedge funds by accident. Then it sent a note to the hedge funds saying, oops, sorry about that, please send us the money back. Some did. Others preferred to keep the money. Citi sued them. Yesterday Citi lost, and they got to keep the money.

Matt Levine. “Citi Can’t Have Its $900 Million Back“. Bloomberg Opinion. February 17, 2021.

At the heart of this problem is a failure to address Employee Experience. Let us get right into it.

How the 3 Key Aspects of Employee Experience Were IgnoredWell Designed User Interface,Workflow Rationalization, andOutcome over outputWell Designed User Interface

Products built for employees tend to have bulky, non-intuitive and laborious under interfaces. Most of these user interfaces are designed by a Business Analyst or worse, by a developer. Using such products requires lots of training, familiarity with jargon and excessive typing/clicking.

All these flaws seem to be present in this case.

The user interface is clearly not up to the mark. It is a primitive design, non-intuitive and does not communicate with a user very well.

Here is why:

1. The number once entered does not add visual markers of a comma. Ideally, the number should have looked like:

Principal: 3,003,000,023

This will immediately tell an employee about the size of the transaction, trigger more attention. Sometimes, giving a worded version also helps. Eg: 3 billion 3 hundred thousand and twenty three.

2. The labels are complex and non-intuitive. That means an Employee has to rely on training and refreshers to know what means what. Most importantly, it all depends if the employee recalls at that moment what means what. See that label:

“Overwrite default settlement instruction”

This check box actually means. “Don’t actually send the money”!

3. In order to complete the action, but not send the money, the employee has to check a box labeled: “Overwrite default settlement instruction”. If the employee misses this checkbox, it is a disaster.

This shows badly designed ‘default action’. Given the prominence of the “Overwrite default settlement instruction” checkbox, seems like “Don’t actually send the money” is not that rare a scenario.

So by default, the money should not have been sent and to send money an extra click was needed.

If a Maker forgot to click the button, the money would not have been sent. That can be fixed easily. Rather than the reverse: where money was sent when it should not have been. That is exactly what happened here.

Workflow Rationalization

Often the workflow is based on the peculiarities of the product in use rather than efficiency or employee experience. That is what has happened here too.

The Fund Sighting Manual explains that, in order to suppress payment of a principal amount, “ALL of the below field[s] must be set to the wash account: FRONT[;] FUND[; and] PRINCIPAL” — meaning that the employee had to check all three of those boxes and input the wash account number into the relevant fields.

Matt Levine. “Citi Can’t Have Its $900 Million Back“. Bloomberg Opinion. February 17, 2021.

This is a tedious workflow. It is non-intuitive, requires muscle memory about the peculiarities of the software and sets up an employee for making mistakes.

That is what exactly happened. The Maker and two other Checkers all missed the fact that only the Principal field was checked off. All three missed that Front and Fund should also have been checked off.

This tedious workflow only forced the hand of fate for such an error to happen.

Outcome over Output

It would be interesting to study how many such requests an employee makes in a data and how many such requested the checkers approve in a day.

Does a busy Manager get assigned checks at the rate where they can inspect the requests?

Does a request come along with a checklist? Ideally, based on the size of the transaction, the possible rules and possible outcomes the request should have a dynamically generated checklist for the approver. In this case, the list could have been:

If the intention is not actually to send the money, are all three (Front, Fund and Principal boxes checked?The current request will lead to the transfer of $3,003,000,023 out of the bank to client. Please ensure this is the outcome intendedThis request usually takes (say) 15 mins to review and approve. Faster approval will flag as ‘at risk’ for the next reviewerConclusion

Obsession with Customer Experience has taken away oxygen from improvement experiences of other Users (mostly employees). Here is a self-check:

Does the internal set of software you use 8-10 hrs a day deliver customer-grade experience to you?

If not, don’t you and the other employees deserve better?

 

The post Ignoring Employee Experience (EX): A $900M Lesson for Enterprises appeared first on Dinker Charak.

Product Decision Records – An Important Tool for Enterprise Product Managers

Every decision has a context. Many times that context is ephemeral. In an enterprise setting products last a long time and teams see a lot of churn. Thus it is important to note the context under which a decision regarding the product was taken.

Every decision needs a review. All decisions are taken at a moment in time and have a context. Thus it is important for decisions to be revisited every so often. This is to ensure the decision is still valid.

Every decision has a scope. All decisions affect a part of the product design or a version of the product. The decisions will also be to address some aspects based on the context of the decision. Thus all decisions have a time/space scope that should be considered during reviews.

Every decision has consequences. All decisions are made to lead to intended consequences. It is important to regularly review if the decision is still leading to the intended consequences. And then there are always unintended ones that time reveals (if your product has that life or adoption).

Thus it is very important to create decision logs for your product. It is an important tool to help teams that work on the products after you to understand the decisions and make better calls as the product evolves. These calls may include what to retain, what to change and what to kill.

And many Enterprise Product Managers have found these to be useful (unfortunately) during Cover your ass arising due to some crisis.

Product Decision Records is one such format to log decisions.

Product Decision Records

I have used the following format to log decisions on the collaboration tools used by various orgs.

Name

Typically, a number and a brief summary. Eg:

PDR001: Have Two Passwords instead of Usually One Password During Login

Date

Many collaboration tools allow you to enter Date using their own component. Try using those as it adds date as structured content.

Status

Possible values are:

StatusDescriptionOpenStill under discussion. But has been logged to facilitate a formal discussion and approval.AcceptedApproved. Either in the implementation stage or already implemented.RejectedNot to be implemented. While it may have been rejected, it is important to log what was rejected.Scope

Mention the Product version or the duration as the scope of the decision

Context

Describe the context of the decision.

Decision

The decision itself.

Consequences

Effects of the decision. Both the desired one and any possible undesired side effects.

Review Trigger

Usually, a time period, change in underlying assumption or known breaking point.

Author(s)

Optional.

Access Sample PRD (Google Doc)

Note: Feature Image courtesy of SERC, Carleton.edu. 

 

The post Product Decision Records – An Important Tool for Enterprise Product Managers appeared first on Dinker Charak.

Project Management vs Product Management: A Flawed Conversation

Introduction

A while ago, Manager vs Leader was a common topic. There were many tables comparing what a manager does vs what a Leader did. The Leader was the clear winner. The Manager, an obvious villain with very narrow and anti-employee attributes.

This format helped in many ways. A simple comparator pushes the message far and wide.

I now see this with Project Mindset vs Product Mindset. The aim of such a comparator is to help others think bigger and wider. A noble goal indeed. However, this approach has some flaws.

It pits Project Mindset against Product Mindset. It presents Project Mindset as a narrow & short-sighted approach.

Take for example the following comparator:

Project MindsetProduct MindsetTemporary teamsLong-lived teamsBuild-once mentalityTest and learn mentalityCustomer feedback at the endCustomer feedback throughout the productRelease onceRelease continuouslySuccess is measured by delivery of scope within time and budgetSuccess is measured by customer satisfaction and value createdScope is determined by stakeholdersScope guidelines are set with stakeholders and teams learn through experimentation and customer feedback

Such comparisons are an example of what I call the Golden Rules of Asserting Superiority: “Your worst is typical of you and should define you. My best is typical of me and should define me.”

Flaws in this ApproachCreates a Bias Against Project Managers

The first flaw is that such comparisons immediately transfer the negativity of ‘Project Mindset’ to the people in the role of Project Managers. The title and role of Project Manager has become less desirable due to unrelated reasons.

During client consulting, I have started noticing this tread more often. More and more ex-Project Managers are moving to the title of Product Manager with minimal or no change in their responsibilities. The change in role is mostly cosmetic. This is more common in Startups and SMEs.

Role Overloading

Now that a Project Manager is a Product Manager, that person is getting over-burdened with additional tasks of a Product Manager. This is over and above the tasks of a Project Manager that have not gone away (because they are important tasks).

Effectively, there is an amalgamation of the two roles leading to additional work and pressure thereof. This is more common in Enterprises.

Devaluation of Discipline of Project Management

Project Mindset is an important part of and not inferior to Product Mindset. Few key things to keep in mind when modelling Project Mindset:

Commitments have to be tracked and met.With Vendors being an integral part of the landscape of an Enterprise, temporary & mission-oriented teams are inevitableIt is a response to a specific construct building a part of or a full product under severe constraints of timeline, budget or peopleAddressing the “Versus”Project MindsetRoot CauseTemporary teams & Build-once mentalityThe temporary nature of teams is inevitable anywhere due to vendor involvement, mission-oriented teams and employee churn. What is important is to ensure continuity of knowledge, experiences and culture.

It is important to close a project with proper experience reports, Decision Logs, and audio/video recordings on anecdotes and casual snippets of information.

Customer feedback at the end & Release onceReduce isolation of the project teams and ensure they are well connected to the teams building rest of the product and also other teams in the Product’s larger ecosystem. This way continuous feedback with reach project teams too.

This also allows the project team to release continuously and contribute to better product-market fit.

Success is measured by delivery of scope within time and budget & Scope is determined by stakeholdersThis is still true as it is important to accomplish something valuable within given constraints. A project team should not be penalised for an improperly defined outcome and guardrails.ConclusionProject Mindset is a subset of Product MindsetProject Mindset is important as it allows teams to accomplish something valuable within constraints of time/budget/people (no org has an endless supply of the above)Project Mindset vs Product Mindset is unfair to the discipline of Project ManagementProject Mindset vs Product Mindset ends up comparing an execution strategy to a product-market fit strategy

 

The post Project Management vs Product Management: A Flawed Conversation appeared first on Dinker Charak.

The Measure of Success, the Zone of Struggle and The Measure of Failure

The measure of Success (tend to be customer-centric) are a common way to describe the success of a product.

“Our Customer Retention score is 90%.”

“Our Net Promoter Score is 80%.”

“Our Churn Rate has never crossed 10%.”

“Our conversation rate from trial to paying is 50%.”

“Our Monthly Active Users are growing at a rate of 210% month-on-month.”

“Our Monthly Recurring Revenue is growing at a rate of 230% month-on-month.”

“Our Customer Lifetime Value is $300 and growing.”

Such metrics are very important and should be well crafted. They allow a business to focus on the right behaviour expected from a product.

The Flip Side of Measure of “Success”

Consider this scenario. You have chosen a conversion rate of 50% from trial to paying customers as your Measure of Success.

Say early in the journey, you see 49% conversion rate. What does that mean? Has it failed? Not really. Just a bit behind but still a success. You continue on the same path along with continuous improvement.

Say instead, you had seen 45% conversion rate. What would that mean? Had it failed? Just a bit behind but still a success? Most probably, you would have continued on the same path along with continuous improvement.

Maybe same at 40% conversion rate.

At what point will the alarm bell ring? At what point will you decide you have some basics wrong and you need a pivot?

Say instead, you had seen 30% conversion rate. What would that mean? Had it failed? Still a success? Most probably, at this threshold, you would decide to go back to basics and maybe pivot.

Say then it falls down to 20% conversion rate. More user studies, more analysis, more advice seeking, more market research. Not calling it a success but not giving up. Pivots and updates would occupy your mind.

Maybe same at 10% conversion rate.

At what point will the alarm bell ring? At what point will you decide you have it all wrong and need to consider closing the product as sunk cost?

Maybe when the conversion rate is less than 5%? For straight 3 months? Even when you have made drastic changes based on real data and feedback? Most probably, at this threshold, you would decide to wind up.

Startups get this. Enterprises won’t. And that is a whole another topic.

A Case for Measure of “Failure”

In my Product Management Canvas, there is a clear place for calling out Failure Metrics. In the example below, there are three clear thresholds:

ThresholdDurationStatusConversion Rate > 30%–Success! Keep learning and keep improvingConversion Rate <= 30%–O Oh! Go back to basics. Something is wrong. We are not successful but we are not giving up either. We will get there.Conversion Rate <= 5%Over 3 monthAm I throwing good money on a bad idea? Am I stuck in sunk-cost fallacy? Time to call it quits? Looks like that.

While you struggle to find the right product-market fit, you have not failed.

Not achieving Success Metrics does not imply failure.

It is obvious that not achieving Success Metrics does not imply failure as in between the two is a large gap, the Zone of Struggle.

Then how does one know when to stop and move on? For that, we need a very clear Measure of Failure.

Measure of Failure

In the above example, it is obvious that Measure of Success and Measure of Failure are distinct measurements and face values. Defining Metrics of Failure is an important activity that we may find hard to dwell on. It is human nature to avoid dwelling too much on the worst case. This is where a disciplined Product Manager can make a difference.

Some characteristics of Metrics of Failure:

Like Metrics of Success, Metrics of Failure is a band of values rather than a single valueUnlike Metrics of Success, Metrics of Failure has a definite time component. In the above example, it is “Conversion Rate <= 5%, over 3 month“.It can be the same as Metrics of Failure but a band on the other side of the spectrumThere is a sufficient gap between Metrics of Success and Metrics of Failure for the Zone of StruggleMetrics of Failure can possibly be a totally different metric than the products Metrics of SuccessThe Measure of Success, the Zone of Struggle and The Measure of Failure

Defining Measure of Success and Measure of Failure is an important part of your Product Ideation process.

MetricsMeasure BandDurationActionMeasure of SuccessConversion Rate > 30%–Keep going. Keep learning. Keep improving.Zone of StruggleConversion Rate <= 30%–PivotMeasure of FailureConversion Rate <= 5%Over 3 monthRecord Learning and wind up.

What’s your experience with this? Please share, especially if you are in an enterprise.

 

The post The Measure of Success, the Zone of Struggle and The Measure of Failure  appeared first on Dinker Charak.

Elevator Pitch Canvas

Why Elevator Pitch?

Imagine this: You come across a high-level exec or say a VC on the way to their office in an elevator. You have an opportunity to tell them about your great idea in the next few mins or so. You can tell them about your idea, why it is such a winner and impress them enough to fund it. Are you ready?

That is the promise of the concept of an elevator pitch— that it should be possible to share the vision + value in the time span of an elevator ride (of one or two minutes).

However, I feel that is not the real value of an elevator pitch. The above scenario and the outcome are highly improbable anyway. The real value is for the founder and the key employees It forces them to think very systematically and clearly about their product.

If you are a founder, you may not find this surprising— that it is extremely hard to put in few words the immense knowledge, the synthesis of the knowledge and opportunities and the vision you have in mind. This is where Elevator pitch makes all the difference.

Introducing The Elevator Pitch Canvas

As the Product Management Canvas, Idea Canvas or the Experiment Canvas, the Elevator Pitch Canvas is a lean innovation tool.

The Elevator Pitch is a lean innovation tool. It allows you to create a brief and easy to memorize description of your product and its purpose.

Ultimately, the Elevator Pitch should sound like a coherent sentence. Eg:

For those with access to the worldwide web Who seek specific information on the web, The Google Search Is A search engine That crawl the web and indexes information in a unique way Unlike Altavista, Infoseek, Dogpile, Yahoo, Lycos, Looksmart, Excite, Webcrawler, AskJeeves, Inktomi, MSN, Overture and AllTheWeb, Our Product uses the number of links to a page (and few other secret tricks) to identify the most relevant result for your search among the first 20 results.

For (Your target customer)

This is where you name your key / most important customer or a very clear + narrow customer segement

Who (Their statement of the need or opportunity)

This is where you call out the key need / pain point / opportunity that you are addressing among those target customers

The (Your product name)

This is where you call out your product’s name

Is A (The product category)

This is where you describe the product’s category.

That (Key benefit / compelling reason to use)

This is where you call out the key benefits. Avoid making this a list and that too a long one. Ideally, the key USP is part of the later section. This is where you try to match the items you put in Who (Their statement of the need or opportunity) section.

Unlike (Your primary competitive alternative)

This is where you list competing products.

Our (Product Statement of primary differentiation)

The key USP of your product.

Get Elevator Pitch Canvas Elevator Pitch (PDF) Elevator Pitch (Google Sheet)ExamplesYour Example

If you have used this version of the Elevator Pitch Canvas to articulate and develop your idea, do consider sharing a non-confidential version with me. I will post it here along with attribution. The more we share, the more we learn!

The post Elevator Pitch Canvas appeared first on Dinker Charak.

How to Build Products that mean Business! – A Product Management Conversation – NASSCOM Vizag

On Feb 27th 2021, NASSCOM Vizag sent out an open invitation to startups in the region (and beyond) to a conversation on Product Management. This is a sort fo precursor to a longer, more involved hands-on workshop.

In this talk I covered the following topics:

7 Reasons Why Your Startup Will Fail6 Traits You Need to Develop as a Founder11 Tools You Should Use To Improve Your ChancesProduct in a box: Hands-on working session4 Roles You Have to Perform as a Founder5 Sales Lessons You Need to Learn

 

Product Thinking for Startups from Dinker Charak

 

The post How to Build Products that mean Business! – A Product Management Conversation – NASSCOM Vizag appeared first on Dinker Charak.

Product Thinking for Startups – A Product Management Conversation – NASSCOM Vizag

After a hiatus of 3 years, I am back to organizing and running Product workshops. This was kick-started with a talk on Product Thinking organized in association with NASSCOM, Vizag. I run these workshop as a way to give back to Startups and Product Management community.

In this talk I covered the following topics:

7 Reasons WhyYour Product Will Fail6 Traits You Need to Develop as a Founder9 Tools You Should Use To Improve Your Chances4 Roles You HaveTo Perform

I have always been fascinated by this comment by Reid Hoffman.

“An entrepreneur is someone who will jump off a cliff and assemble an airplane on the way down.”

This is how my startup experience was. I had a check from an investor before I had an idea in place. That is a story for another day.
I kick-started the call by asking attended:

What would you assemble first?

[  ] Wings

[  ] Engine

[  ] Landing Gear

[  ] 1st Class Seating

Of course, there was no right or wrong answer. It was wonderful to hear the various answers and why they chose that option.

Maybe if you attend my next workshop or organize a workshop at your organization, we will get to hear even more interesting answers. You can read more about the Product Management workshop here – Hackathon: From Idea to a Product in a Day.

The post Product Thinking for Startups – A Product Management Conversation – NASSCOM Vizag appeared first on Dinker Charak.

Why Triple Diamond is a Better Paradigm than the Double Diamond

Around 4 years back, I started using the paradigm of Triple Diamond over the Double Diamond. The British Design Council developed the Double Diamond to describe the design process. Recently, many people are writing about the limitations of the Double Diamond paradigm. I wanted to revisit this topic and add my learning since.

A Recap of Double Diamond

The first key concept behind the Double Diamond is that of a diamond. The diamond represents the divergent followed by convergent thinking during the design process. The second key concept is the juxtaposition of two diamonds. These two diamond represent the divergent and then convergent thinking during the discovery of a product followed by the creation of the product.

Details of each diamond can be found in my earlier post.

So, What’s Missing in the Double Diamond Model

The Double Diamond assumes that Product Design starts with the discovery of a product via divergent thinking. This is followed by arriving at a definition via convergent thinking. However, my experience as a Founder and then as a Product Manager makes it apparent that there is a step before this. A diamond at the beginning is missing.

Introducing the Zeroth Diamond

Much before the discovery of a Product begins, there is an opportunity that shows up. Exploring the opportunities, and then converging to a strategy to benefit from the opportunity is where it all begins. In order to represent that phase, both for Founders and Business Leadership, I have found the Triple Diamond to be an excellent paradigm.

Opportunity: A Greenfield or blue-sky projects, may need to scale, create a new business line, transform the existing organisation, etc. The Opportunity phase is where you explore possibilities.

Strategy: The Strategy phase used Digital Transformation, Product, Data, Design thinking to come up with strategy roadmap. Here we define the strategy to tap into the opportunity and state problems that need solutions via a product.

Summary

Double Diamond starts with Discovery of a Product
It does not reflect the reality of divergent exploration of opportunity and then convergence on a strategy to address the opportunity
Triple Diamond address this via a zeroth diamond of Opportunity-Strategy pair

Hoping to hear your experience with the Double Diamond and the benefit of Triple Diamond paradigm.

The post Why Triple Diamond is a Better Paradigm than the Double Diamond appeared first on Dinker Charak.

Use Pricing Table to Define & Describe Your Product

While a Product Management Canvas is an internal-facing tool to describe or imagine your product, Pricing table is an excellent external-facing tool to describe or imagine your product. Let us explore why it so and along the way list some key things to talk about in a pricing table.

A Way to Describe Your Product

What if you had to make a single page product note or a pitch for your product? As an ideator and/or as a product manager, what all would you include in the product note to describe your product? What describes a product crisply?

Consider these:

Key features that make your product useful and valuable
Additional features that allow someone to use your product under some special circumstances and at scale
How much your product cost based on usage, audience or scale
All this presented in a pictorial/graphical manner
Easy way to buy the product

Isn’t that what a Pricing Table format (as made popular by WordPress and other template-based website builders), really is?

A Way to Imagine Your Product

If we flip the scene and instead of communicating about your product, you are planning to build a product. How can a Pricing Table help then? A pricing table forces you to:

Key features that make your product useful and valuable
Additional features that allow someone to use your product under some special circumstances and at scale
Allow a variety of users try your product based on usage, audience or scale at different price points
Present all this information in a very succulent in a pictorial/graphical manner
Above all, make it easy for someone to access your product with a low friction buying process

With the value prop and price next to one other, the pricing table forces the Founder / Product Manager to confront the question: For this, will someone pay this much?

If you have figure this out for your product, you have a path to success shaping up in front of you.

Feature Image Courtesy – Colorlib.com and In Article Pricing Table Courtesy – Ostinato.org

The post Use Pricing Table to Define & Describe Your Product appeared first on Dinker Charak.

User Manual Template

Product Managers often write the User Manual for their product. This may be the final version or an input to a technical writer. Here is a template I have used to get started on numerous occasions.

Contents of a User Manual

Call out your audience. A product may have used by multiple types of users who may have a distinct user journey. Ideally, have a User Manual for each of the user type.
Name and intro the product. The official name, aka names (ever struggled with Mac OS X names and its actual version number when searching google for a solution for an issue?), version, logo, icon and a brief note on what the product does in the context of the audience user type
Quick Start. A shortest, most direct userflow with no exception flow to get started, do a ‘hello world’ action and exiting. A tl-dr or ‘for impatient’ version. Best to use screenshots a lot with labels and annotations
User Flows. If there are multiple userflows, address each of the user flow per chapter. Start with a brief note on the flow, what it entails, what it accomplishes, and what could go wrong during the flow. Best to use screenshots a lot with labels and annotations
List of Error messages. And possible cases and next steps
Contacting Support or public forums where additional help can be sought
FAQ. Have one even if you have to start with just 1 questions but keep it growing

Meta

Have a uniform structure and template (user should know form the page layout, margins, colours, design what the page is about)
Have useful footers (page, product name and version)
Give meaningful titles to images
Have an index of image
Always assume your user is a novice who will follow your manual down to the last word
Do hand over the drafts to someone who is not familiar with the product and seek feedback if the information was useful enough
Choose Portrait mode (Word doc) if your users will print it more often and a Landscape mode (Powerpoint presentation) if your users will look at it onscreen more often

Have fun writing!

Feature Image Courtesy Peter Merholz (Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) ).

The post User Manual Template appeared first on Dinker Charak.