For a fully remote company, Slack can be described as the digital headquarter.

Leveraging slack wisely is crucial for us to work efficiently as an remote organization.

Here are some tips on using slack.

Slack Channels to use

Creating the right slack channels is the first step towards this. It helps information flow in realtime to the relevant users.

Here is the list of slack channels that I have seen come in very handy

• #live-issues-production — Any urgent customer issue that is preventing the customer from using the product is posted here. (Messages posted here demand immediate attention and must be resolved immediately. The tech support team and the on-call engineer are the first responders here)
• #bugs — Unexpected behaviour encountered in the product by anyone in the company is posted here. People should ideally add screenshots or a walkthrough video to make debugging easier. The product/engineering team is expected to track this channel closely and create tickets for the bug reported. Based on the severity of the bug, the team takes a call on prioritization. (Without this, the team would not be share where to post information regarding bugs)
• #product-feedback —Suggestions for improvements in the product or development of new features are posted in this channel. The product feedback can come from various sources — internal team sharing their own ideas, sales team posting requests from their prospects, account management and support team posting feature requests from customers. (For requests from external customers, its advisable to share feedback in a format that captures customer name, use case, deal value etc. This will come in helpful at the time of prioritization)
• #sales-faqs —Queries received by the sales team while interacting with prospects during conversations or on emails are posted here. (Frequently asked queries should eventually be added to the training material and knowledge base articles associated with the respective features.)
• #won-deals, #lost-deals — Information related to deals which are won or lost is received in these channels respectively. Sales reps do not need to post in these channels. You can directly hook any CRM software you use (say Hubspot) and have it directly send information to these respective slack channels whenever an update is made on the deal status. (Track these channels closely to understand what’s working and what’s not working for the product)
• Department wise channels —There should be a public channel for every department. This can be joined by people not part of the department channel. For example — #dev, #design, #product, #marketing, #growth, #customer-success. (Information/Announcement relevant to a particular team or questions for a particular department or updates/announcement from a particular department are usually posted on the department wise channel)

Department wise channels come in handy in the following ways:

1. Any information or announcement that is relevant to all the members of a particular department. For eg. a process change which all the developers should follow can be communicated via the #dev channel.
2. A general query regarding a particular department which you are unsure where to post can be added here. For eg. if you are looking for a Figma link for a particular feature, query can be posted in #design channel. Or if you want to suggest a correct in a promotional article, it can be posted in #marketing department.

• Team wise channels — Teams work better when there is a space for them to share ideas, discuss progress and call out issues. These channels would be ‘private’ by default as people not part of the team should not join.
• #random — To post any non-work related stuff. For eg. memes, jokes etc.

#General — The Company Wide Channel

There is a channel called #general where the entire company is added by default.

Use this channel to communicate company wide updates/announcements, policy changes, employee promotions, new marketing campaigns, giving shoutout to top performers, testimonials from customers etc.

Basically, any information which the entire company should know goes into the #general channel.

Temporary Channels for New Initiatives and Projects

Any discussion around a project should always happen on the appropriate channel. (Having project discussions on Direct Messages is problematic and leads to lot of people missing out on context)

At the start of a new project, initiative, upcoming event etc, create a temporary channel where all the discussions, updates regarding the project will happen.

All team members who are working on the project or who need to be looped in regarding any changes in the project should be part of this channel.

We usually keep these channels as public (unless its a confidential project) so that everyone interested in the progress of the project can join in.

Use the following in built slack features to level up your project management — Automatically send reminder for status updates, bookmark all documents and supporting material, use huddle to discuss open items.

Once the project is over, the channel can be archived (deleted).

Keeping Channels Public

We default to keeping most of the permanent and temporary channels “public”. This ensures that anybody can join this channel anytime and follow the content being posted. This helps in creating a culture of “openness” and “transparency” in the organization. Besides, it also gives an opportunity for people in the organization to comment on messages where they might have something useful to contribute.

Slack Connect to bring Customers and Vendors within your Slack

Slack Connect is an amazing capability offered by slack that allows you to talk to customers or vendors while staying within slack itself.

Having a common channel with your big ticket customers helps you answer their queries faster, share latest updates and get feedback on your ideas faster. I have managed to set up calls with customers by sending a simple message in our slack connect channel.

We also use slack connect to communicate with our vendors (organizations whose product & services we are using). This helps us convey our issues in real time and get faster response to our queries

Use Integrations to reduce switching between tools

The real power of slack is unlocked when Slack is integrated with the workspace tools you use. You can receive updates from the tool within slack itself. Additionally, once the tool is integrated, using shortcuts you can perform bunch of actions using the tool while staying inside slack.

These are some of the integrations that help me make more efficient at work everyday — Google suite (Calendar, Drive), Loom, Typeform, Figma, Gong, Hubspot, ClearFeed. For example:

1. We use typeform to get feedback from users. Through the slack<>typeform integration, the feedback from a customer is sent directly to a slack channel so that the teams can read it and take action.
2. Using the Google Calendar integration, I can do the following actions from within slack itself: create a meeting, accept/decline meeting invites, join meetings.
3. Using ClearFeed, we can keep of track of issues reported by customers (and follow up on them with the developers) while staying within slack.

To check if your workspace tool is available for integration with slack, you can check out Slack’s app directory.

Things to Remember

• Do not use slack as a substitute for proper documentation. Use a proper document collaboration tool (like Google Docs) for that.
• If not used carefully, slack can end up being a productivity killer — too many unread messages, constant notifications, firefighting all the time. So, tread carefully here.
• Informal Meetings are required to build a rapport among the employees — Here’s how you can do it

Slack is a fantastic workplace communication tool which was made remote work seamless and efficient for us.

Hope the above tips help you do the same.

Additional Reading

• Staying Productive while using slack
• https://slack.com/intl/en-in/resources/using-slack/slack-remote-work-tips

How a remote organization can leverage Slack to run itself effectively and efficiently was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

If we have data, let’s look at data. If all we have are opinions, let’s go with mine — Jim Barksdale, former CEO, Netscape.

If you search the internet for quotes on importance of data, you will find tonnes of them.

Most companies and leaders claim to be ‘data driven’ in their decision making and expect their employees to be the same.

Yet, being data driven is easier said than done.

Many a times, numbers are used as an afterthought. They are meant to back a decision that you are leaning towards rather than actively help in forming a hypothesis or making a decision.

However, once you start your professional career, you are expected to have date backing most of your decisions. Having data-backed arguments helps you stand apart from the crowd of fluffy, opinionated people.

In this article, we will learn everything it takes to become more data driven — starting from challenges, moving to various techniques for analyzing & visualizing data and finally concluding with strategies to inform & convince others using data.

Let’s dive in.

Challenges in becoming data driven

Following are some challenges faced by PMs face in their journey of becoming more data driven.

1. Not Comfortable with Data Analysis

You have never really used or been trained to analyze data and find out insights. Given a problem, you are not sure what data to analyze, how to analyze it and extract insights.

2. Missing Data

Very minimal data logging has been one for your product. Whenever you seek data for a analyzing product usage, you find crucial data missing.

3. Lack of DIY (Do it Yourself) Systems

You know the data that you need. However, you are not familiar with the tools used to extract data. Thus, you are dependent on someone else for providing you the data. This leads to inordinate delays and makes it impossible to be data driven.

Next, we look at how to overcome each of the above points.

Mathematical concepts to understand

You don’t need to be a Math's whiz to gather deep insights. But there are some basic concepts you need to be clear about. These include:

Percentage

They are a way to express something as part of a whole. For example if 5 out of 100 users click on an advertisement, then conversion rate is (5/100) = 20%.

As a PM, most of your measures happen in terms of percentages. For eg. percentage of users who converted from free to paid, percentage of users who clicked the ad, percentage of users who liked the ice-cream.

Changes over time are also often reflected in terms of changes. This helps identify the magnitude of the change. For eg. our user base has grown by 70% since last year.

Percentiles

It involves dividing data into 100 equal parts, with each part representing a percentile. So, if we say that a value is at 95th percentile, it means 95% of the values are less than that.

There are certain metrics where just measuring the average is not sufficient and you want to focus on outliers (so that their experience can be improved).

For eg. in case of website load time, you would want to consider the 90th percentile for website load time. Say, its 1 second. This means that for 90 percent of users, load time is less than 1 second. For remaining 10%, its more than 1 second.

Mean

It is the average of all values in the dataset. It is calculated by (sum of observations)/(number of observations).

You can use it when data is well distributed and there are not many outliers.

Median

It is the middle value of a dataset when it is arranged from smallest to largest. Use medians when your data has outliers (i.e. there certain datapoints which are significantly smaller or larger than the rest of the data).

Correlation and causation

Correlation means that two variables seem to exhibit similar trend. For example, if variable A is moving up then variable B is also moving up.

Causation means change in one variable is influencing another variable. For eg. when variable A increases, it causes variable B to increase.

Correlation does not imply causation.

For eg. both variable A and B might be moving up because of another independent variable C.

Use for PMs — Say, you want to understand which features lead to a higher retention rate. Understanding causation between a feature’s usage and retention would be critical. This would help focus on features that are actually moving the needle.

Analysis Techniques for Drawing Insights

Here are the three popular ways to analyze data and extract insights:

Trend analysis

It involves collecting data over a period of time and then analyzing data to identify patterns or predict future.

For eg. i) Looking at revenue or customer growth over last few quarters to understand the change and forecast future revenue or customer growth. ii) Looking at feature usage data to understand the pace of a new feature’s adoption.

Funnel analysis

This method is used when users are moving through a multi-step journey and you want to understand what % converted and what % dropped off (at each stage). User journey acts like a funnel because out of all the users entering the top, only a few reach the bottom.

Useful when you are trying to understand your onboarding flow, buyer journey (imagine all the steps that a buyer on an e-commerce site goes through), booking flow (imagine the steps user goes through while booking a trip) etc

Cohort analysis

Cohort refers to a group of users with similar characteristics or usage patterns.

In this analysis, you take a ‘cohort’ of users analyze their usage pattern or interaction with the product.

There are primary three types of cohort data — acquisition cohort (group users based on when they sign up), behavioral cohort (group users based on past behaviors or user profile), predictive cohort (group users based on how they expect to behave in future)

*Behavioral cohorts — Ability to group users across fields such as pricing plans, device type, geography, company size, age etc can be a powerful way to identify insights.

Deciding the data points to track when a feature is shipped

One common mistakes which PMs make is that they forget to ship the analytics with the feature.

To prevent this, do the following:

1. Add an ‘analytics’ section to your PRD template — Having this in the template ensures that you don’t forget about analytics.
2. Make ‘checking for analytics’ part of your testing process — QA team is explicitly mandated to call out if analytics is missing from the PRD.

To identify what analytics to ship, follow this 3 step process:

1. Identify the questions you want to answer — Here, the goal is to identify what all questions would you want answered once the feature is released.
2. Identify the metrics which need to be tracked to answer the above questions.
3. Identify the event signals that need to be sent to track the above metrics

To learn more on the above process with the help of an example, read this article.

Visualizing the data and Communicating Insights

Here are the various formats in which you can share data with the stakeholders

• Tables — Useful when you want to summarize multiple metrics relevant to a specific aspect of business in a single view— Source

• Line chart — This connects a series of data points using a straight line. It represents a sequential progression of values (usually over time). For eg. change in stock prices, website visitors etc.
• Bar chart — It helps compare numerical values like integers or percentage. The value is indicated by the length of the bar.
• Stacked bar chart — It extends the bar chart to look at numerical values across two categories simultaneously. For eg. when you draw a bar chart for indicating monthly revenue, then in each bar you could indicate the revenue change due to churn, downgrade, upgrade, new revenue.

While its easy to go down the rabbit hole of various visualization techniques, the above charts should suffice for most cases you will encounter .

Tips to remember while sharing your analyses with a colleague or a boss

• Before sharing data, think about who your audience is — Your audience determines the format in which you present the data.
• Start with the key insight you want to share — Keep the numbers or graphs for later slides. This convinces the audience that its worth their time to try understanding the data.

Additional Points to Remember

• Remember to log data for every feature you ship — Otherwise, you would never be able to understand or demonstrate the impact of your features.
• If numbers look too good/too bad to be true — Get a data sanity check done on them. Discovering that you are analyzing incorrect data during review meetings can cause lot of damage to your reputation.
• Invest in setting up Do-It-Yourself (DIY) dashboards — So that you don’t have to spend days waiting for the analyst to respond to your request. This also allows other stakeholders to access these dashboards and deep dive into the data.
• Have periodic meetings with leadership for reviewing data — Having a forum such as weekly business review or a feature usage review, ensures that everyone is on top of the metrics they own. It becomes a place where people can discuss the insights from data, identify anomalies in advance and plan actions to take.

Conclusion

Being data driven is essential if you want become a better leader.

It helps you improve your decision making process, lends credibility to your arguments and helps you learn faster from mistakes.

But looking at the right data in the right way matters. Otherwise, you might end up vanity datapoints which could do more harm than good.

So, its time to put the above strategies into practice and start the journey towards becoming a data driven leader.

Further Reading

• https://gopractice.io/data/arithmetic-mean-and-median-for-product-managers/
• https://gopractice.io/data/correlation-and-causation/
• https://amplitude.com/blog/causation-correlation
• https://amplitude.com/blog/cohorts-to-improve-your-retention
• https://www.atlassian.com/data/charts/essential-chart-types-for-data-visualization
• https://equals.com/guides/saas-metrics/appendix/operating-model/
• https://productlessons.substack.com/p/were-using-numbers-wrong

How can PMs become better at analyzing data, visualizing data and convincing others using data was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

When it comes to professional development and learning — your boss matters as much as the company you are in.

A good boss can help accelerate the growth of their reportee and leave a lasting imprint on their reportees career.

During the course of my product management career, I have served under three different bosses. Additionally, I have managed two product managers.

Each manager had their own working style and expectations from me. My experience of working under each one of them has brought a different set of learnings about myself and being a manager.

This article is an attempt to share those learnings and help aspiring managers become better at ‘managing’ professionals.

Examples of ‘bad behaviour’ by a boss

• Not taking responsibility for a poor experience shipped to production which they had reviewed earlier. (Instead, throwing your reportee under the bus)
• Having an abrasive communication style which shatters the self-confidence of your reportee.
• Never ever trying to understand the career aspirations of your reportee — only focusing on project delivery.
• Giving terrible performance ratings with random reasons that were never brought up during the course of the year.
• Changing plans and deliverables midway without giving any reasoning on why the plan is being changed.

I am sure you too will have your fair share of stories of ‘bad boss behaviour’.

Let’s see what we can do to fix that.

Principles to adopt for becoming a better boss

As a manager, use the following key principles to determine the day-day tactics you should adopt to manage someone.

1. Build trust by communicating regularly, providing coaching and having their back in times of difficulty.
2. Empower them by helping them define their goals and then giving them autonomy to operate and take decisions.
3. Take interest in their professional growth by helping them identify their blind spots, sharing honest feedback and understanding their career aspirations.

While these principles are simple, they are not easy to implement in practice. With the stress of deadlines & commitments, working relationships tend to become narrowly transactional and focused on project deliverables and hitting of metrics.

But eventually, such narrowly ‘transactional relationships’ lead to sub-optimal outcomes for both the manager and the reportee.

Putting in a little effort and bringing discipline to your management approach can create conditions to enable the reportee to put their best foot forward.

Translating Principles to Everyday Actions

Here are the actions you can perform to put the principles into practice.

Weekly 1:1 meetings

Regular meetings between the manager and the reportee helps build trust and lays the foundation for a solid working relationship.

During these 1:1s, avoid focusing on task updates.

Instead, managers should focus on — understanding how things are going, whether the reportee is enjoying their work, what are the roadblocks they face and what can the manager do to help them perform well.

Here’s a great article by Rukmini Reddy (former SVP, Slack) on running 1:1s — Link

Give Negative feedback quickly and promptly

The best managers I know don’t wait for the appraisal discussion to give negative feedback. They strike while the iron is hot and use it to nudge their reportees in the right direction.

As a manager, ‘striking while the iron is hot’ means give negative feedback the moment you notice your reportee did not perform a task as expected. When the incident is fresh in everyone’s mind, its easier to have an accurate discussion on what went wrong.

While giving negative feedback, focus on the following — the context, what went wrong and what was expected.

Take care to not be abrasive while giving the feedback. I had one such manager. Though they gave negative feedback quickly, it was always ‘about my incompetence’ and stripped me of my self-confidence.

On the other hand, another manager of mine used to preface the negative feedback with how they had high expectations from me and expected me to do better. Even though the feedback was negative, I always resolved to do better after the discussion happened.

Define Clear Goals and KPIs for measuring performance

Great managers create clarity.

As an individual, I must have an understanding of doing what will help me and the company achieve success.

As managers, working with the reportee to set clear goals and KPIs on which their performance will be measured, helps them plan so that they optimize the work that will help them hit those goals.

It must be remembered that for most roles, KPIs can’t be reduced to a 1–2 business goals. In this case, other factors such as how easy it is to collaborate, decision making abilities, strategic thinking etc should also be identified as the factors for measuring performance.

Give autonomy and ownership

The best way to sabotage someone’s career is by consistently micromanaging them.

While some degree of handholding might be required for freshers, you need to gradually let go. Else, the other person will not apply their creativity and skills in the work. They will just do what is told to them.

As managers, we should give our reportees the goal or the problem statement and then let them figure out the solution and the process to build that. (The scope of the problem can be determined based on the person’s level of experience)

As a manager, you can set up check-ins, review meetings and deadlines to ensure things are as per expectations and on time — But let your reportee take ownership of delivering things on time.

Shine the spotlight on them

People tend to grow faster when they know that their work is sufficiently visible in the organization.

I have been lucky to have managers who never tried taking credit for my work. They would always let me be in the spotlight when we had to showcase the team’s work.

Some practical ways of doing this — Nudge your reportee to speak up during team meetings, ask them to present in review meetings with leadership and allow them to make important feature announcements. (Don’t worry about losing credit — If your reportee does a great job, lot of credit will go to you as a manager)

Teach adherence to processes

When people enter the corporate world, they don’t realize the importance of adhering to processes — for eg. sharing regular updates, writing comprehensive documents, following checklists etc.

Subsequently, when things get delayed, they scratch their head as to why it’s happening.

As a manager, your past experience gives you foresight on how things may go wrong. Use this for coaching.

I would recommend using examples from your personal experience to drill the importance of adhering to process in your mentees.

Career Conversations

Once every quarter, have a career conversation with your reportee.

Understand the following — How they are looking to grow in their career, are they satisfied with their current work, do they find the work challenging. Most importantly, try to understand what you can do to accelerate their learning and impact in the organization.

Conclusion

Getting a chance to manage someone is both a privelege and responsibility.

If done well, it does wonders not only for someone else’s career but even for your own career.

So if you are a manager or about to become one soon, do try to bring the above approaches into action. I am sure it will change the trajectory of your working relationships and set up you up for success as a manager.

Additional Reading

• https://blackboxofpm.com/managing-and-developing-product-managers-2f9a3963fab6
• https://www.linkedin.com/pulse/how-structure-great-11-conversation-brad-porter-ve2xc/

3 Managers and 2 reportees later -here’s what I learnt on being a good manager was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lessons learnt from shipping features that broke the user experience

There is a significant downside to equating success to “shipping the feature” rather than evaluating the customer’s experience of the feature.

In such a scenario, its easy to lose sight of the wood for the trees. You are just ticking off a checklist when you are shipping a “useful feature”.

Ironically, shipping this “useful feature” has the exact opposite effect of your original intention— It does not end up being useful at all. Customer’s don’t use it or give up while trying to use it. Even if they do use it, they have tonnes of complaints and never seem to be happy.

Failures that serve as painful reminders

Here are some instances I can recall from my time as a PM at a virtual events platform:

• A visual enhancement meant to improve the live event experience invited a lot of backlash from one of our customer. (Reason: It broke the experience for the customer’s ongoing event and their participants had a tough time finding the activity of their choice)
• A promising new feature with the goal of increasing participant turnout caused a customer to churn because it had the opposite effect — decreasing participant turnout. The registration experience created confusion among registrants which led to a low turnout. (Reason: The product communication and edge cases were handled poorly.)
• One of our product capabilities pissed off a customer so much that he took to social media to vent his anger. (Reason: Some critical flows in the capability was missing. The existing capabilities were cumbersome to use and the customer had to spend lot of time just getting things to work)

All these instances serve as a painful reminder of the perils of being over obsessed with shipping.

When users are shortchanged through a poor user experience, they will likely churn.

What does ‘Delightful user experience’ mean

To me, user experience refers to the user’s journey of engaging with the product and deriving value from it.

Delightful user experience would be measured by how easy it is for the user to:

• Perform the intended task(s)
• Find features, set them up and reuse them
• Figure out how to proceed in case of an error or a failure

In addition, a delightful user experience also indicates the aesthetic appeal of the platform — which refers to the look & feel of the User Interface, the visual elements such as colors, typography, buttons used.

So, you can see that user experience goes much beyond just shipping a ‘useful’ feature.

It looks at the entirety of the user journey.

Steps to craft a delightful user experience

Here’s how you can focus on crafting a delightful user experience by looking at the various stages of the feature development lifecycle.

Design Phase

This is stage where you lay the foundation for crafting a delightful user experience.

Empower the design team to focus not just on the feature being built but also address the following:

• Problem being solved — Articulate the problem being solved. Revisit this continuously during the design phase to ensure your design solves the problem you set out to solve.
• Feature discovery — Where exactly does the feature show up in the product? Is it present at a place where the user is likely going to look for it.
• Feature onboarding —How will the experience of a first time user look like? How will they understand what the feature does? If they need more help, will there a handy help article/video for them to access?
• Feature workflow — How many steps does the user need to go through? What is the information shown at each step? Is the information necessary and sufficient for the user to proceed forward?
• Different user journeys — For platforms with different types of users (for eg. participant and event organizer), take care to craft and review each type of user’s journey independently. (Based on my experience, the user journey you ignore will come back to haunt you during the testing phase)
• Handling failures and errors — Its inevitable that your feature might fail in certain scenarios. (For eg. if you take a file as input, the file upload may fail due to its large size or incorrect format). May sure you have handled this through crisp, concise error messages. These should help the user understand what went wrong and how they can fix it.
• Aesthetics — Aesthetics refers to the visual elements such as typography, colors, buttons which determine the look and feel. Products which are designed aesthetically act as the icing on the cake and take the user experience to the next level. (Empower visual designer to work their magic here)

Before handing the feature off for development, its always a good idea to do usability testing of the feature with customers and internal teams.

Testing Phase

Testing out the product reveals gaps more efficiently than any other exercise. Until now, all you had were design screens. Now, you have a working version of the feature.

Here’s what I would recommend you to do.

• Test out the basic flows of the feature yourself — Don’t just rely on the QA team for testing. You know the ins and outs of the feature — Nobody else will notice the gaps you will.
• Invite team members from outside the tech team to test — Get people from the support and sales teams to test out the feature and give feedback. They will bring a fresh perspective that will leave you amazed.

Incorporating the gaps discovered during the testing phase helps polish the feature for release day.

Launch phase and Beyond

Your plan is to delight users and not surprise them.

Don’t release features without giving sufficient notice to the teams and customers on what’s being launched. The information should include — What’s being launched & when, problem being solved, customer benefits and a walkthrough video or screenshots.

Any potential impact on the existing workflows of customers should be called out so there is no disruption in the customer’s day-day activities.

Release complex features in Beta — It doesn’t matter how much effort you have put in to craft the user experience. Customer’s often test a feature to its limits. Having a ‘beta’ tag helps you set the right expectations with customers. It also helps the possibility of a quick rollback in case things don’t go according to plan. (Caution — Don’t let features stay indefinitely behind feature flags. Be aggressive on gathering feedback , iterating on it and making the feature available for all the relevant customers)

Keep track of the early adopters and ask them their experience — Talking to them gives you an insight on the customer perception. If the goal is to create exceptional experience, you shouldn’t be satisfied unless you hear superlatives from your customer — like “wow”, “amazing”, “exceptional”!

If you want to make your product a compelling proposition for the user, care must be taken to craft an exceptional user experience. This leaves a deep imprint on the user’s mind and creates a high recall value.

So, the next time you get to work — Don’t just build a useful feature. Focus on crafting delightful user experiences.

This will earn you customers who are not just paying users, but lifelong advocates and raving fans.

How and why PMs should focus on crafting delightful user experiences instead of just shipping… was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

My favorite part of being a Product Manager is talking to users.

After becoming a product manager, I took to user research as a fish takes to water.

Building a product used by people across geographies and industries helped me connect with people from diverse backgrounds and at different stages of their career. Such conversations are quite enlightening and helped me understand the impact of my product.

In this article I want to discuss everything I learnt about user research — different types of user research, identifying users to talk to, questions to ask them, communicating insights, quick ways to do usability testing and gathering insights from data already available to you.

Let’s dive in.

Two types of user research

Depending on the purpose, user research could be either of the following:

Generative user research — The purpose is to understand your users better — what they do, what are their goals, what are their expectations & pain points (in the context of the product you are building).

Evaluative user research — It helps you evaluate the usability of a particular feature or a workflow (eg. onboarding, checkout etc). It could be done either with a design prototype or with the live version of the product. It helps you understand the following about the product/feature — how easy it is to use, what do users like/dislike, what are the information & design gaps.

As a Product manager, you will do both generative and evaluative research.

Identifying users to talk to

Lot of people are not able to find relevant users who will be interested in connecting and sharing insights. A lot of time seems to be wasted in simply finding the users to talk to.

My advice here would be to:

1. Get started early — It takes time for people to respond to your outreach. Meetings are usually set 1–3 weeks after the first response.
2. Build a relationship with customers— Regularly send them updates, proactively address bugs reported by them and be responsive to their outreach. This will make it easier to setup feedback calls with them.
   (We have setup slack connect to message our customers from within slack itself)
3. Take help of internal teams to setup calls with customers — For example:

• Take the support team’s help in setting up calls with customers who are asking queries or raising complaints via the support channels.
• Take help of the account managers to reach out to customers mapped to them. (You can also join the monthly/quarterly touch base calls conducted by account managers)
• Take help of sales team to talk to prospects who are actively considering airmeet and have feature requests
• Take help of user education and onboarding team to reach out to customers who have just been onboarded onto the product.

Using the above, you can hopefully avoid the problem of “not finding users to talk to.”

As product managers, you should also have access to your product analytics and CRM tool so that you can quickly filter out customers based on segment, use case, company size, feature usage etc. Doing this reduces dependence on others for finding the target customers to reach out to, thereby making the entire interview scheduling process faster.

Reaching out on email and scheduling time

In case you are doing a direct outreach via email, share context and the questions you may have. Include a meeting scheduler link as well so that users can book a meeting as per their convenience.

If I am reaching out for feedback on a particular feature, I tend to include 2-3 questions in the email itself. The user is free to respond to them via email or book a meeting with me.

Asking the right Questions

Asking the right questions is everything. It is the single most important factor in determining the richness of the insights you capture.

Some useful tips to remember

• Break the ice with a warm introduction
• Keep your questions short, simple and precise
• Avoid Yes/No questions and ask open ended questions
• Listen way more than you speak
• Understand their past experience — Ask them to describe the last time they used the product. What was their experience like?
• When they make feature requests, delve deeper. Understand the underlying user need.
• If you are trying to understand the feedback with the complete product — break down the questions into various stages of the user journey. (For eg. as a PM at a virtual events platform, I break down the questions into pre-event experience, live event experience and post-event experience)
• If you are seeking feedback on a particular feature , you can focus on the following — what problem does it solve for you, what was your experience of using it, what would you like to improve on this?
• Have the questions ready before the user interview begins — Otherwise, you will be scratching your head during the interview process.
• If its an existing user, see if you can gather insights on their product usage — This way, you can ask them highly contextual questions around their usage.
• To reduce rework for every interview, prepare a document with the standard questions you want to ask during the user interview.

Here’s a detailed guide I have previously written on conducting insightful interviews — Link to guide

Capturing and Communicating Insights

Record all user interviews you do. This way, any team member (including you) can refer back to them in the future.

Don’t worry too much about taking meeting notes. This distracts you from asking good follow up questions to the user. Every recording software automatically generates interview transcripts and summaries — So, rely on this technology for notes.

While summarizing interviews, I break it into the following parts:

• Introduction about the customer — name, industry, use case, deal value
• Details about the customer’s use case — goals for using the product, frequency of usage etc.
• Customer’s pain points and expectations— What activities is the customer struggling with, what features are missing etc.
• Key themes — you also want to highlight the key theme emerging from your interview. These would help identify product areas or key tasks that users are struggling with. The ‘themes’ which reoccur across multiple interviews can then be considered for prioritization during roadmap planning.
• Getting screenshots (via screenshare) and customer quotes is also useful for explaining the customer problems to design and engineering.

Communicating insights is as important as conducting interviews to capture insights.

Useful tips to remember while communicating insights:

• Don’t wait too long to share the insights — Share these as soon as the interview is done.
• Share them as widely as possible — We have a #product-feedback channel (on slack) where most of the company employees are present. I share all the interview summaries there.
• Make the insights memorable by sharing customer quotes, screenshots and crisp summaries. (Make these quotes and screenshots part of your PRDs)
• Use product/design team meetings to discuss these insights and plan action on them — When everyone reflects on the insights, they are much more likely to act on them.

Using Evaluative Research for Usability Testing

As mentioned above, PMs need to do evaluative research as well. This is useful for testing out the usability of your upcoming features or existing workflows.

Usability testing is a way to find out gaps in Information architecture, UX copy or the visual design in an upcoming feature or the existing product.

The best practice here is to have a clickable design prototype. (Figma makes it very easy to create clickable design prototypes)

Here’s the process and some tips to do this well:

• At the start, the user is given a set of tasks to perform — For eg. in an e-commerce product, task could be how you search for a product.
• Give no more than 3–4 tasks — Otherwise it might become too overwhelming for the user.
• While performing the task, the user is expected to talk out aloud about what they see, what they understand and what do they expect to happen when they click a particular button. (Talking out aloud is very important as you want to know what the user is thinking)
• Towards the end, you could also ask the user — How would you describe the feature to a co-worker? (This can aid the product marketing efforts)

Researching with internal teams instead of users

Sometimes, you are running short of time. And can’t seem to find relevant users to test your feature.

In such cases, take the support of your customer success and sales teams.

Share the design with them and ask for their feedback —This can help you identify gaps and usability issues. While its not the perfect method for testing, something is better than nothing.

Using sales conversations for user research

You can’t possibly talk to every customer and prospect that’s out there.

A lot of insights can be gleaned from simply listening in to conversations that your customers/prospects have with your sales and account management team.

Here’s the process I follow

• Periodically log into Gong (It is the platform we use for recording all our customer interactions).
• I go over the summaries of all the conversations which seem relevant. (Gong automatically summarizes conversations and highlights key points from that)
• There are two kinds of interactions which are relevant

1. Prospect interactions —Use these to understand why prospects are looking to buy your product, what are their expectations and what are the gaps in the existing solution?
2. Customer interactions — Use these to understand how regularly are customers using the product, what are their pain points and what more do they expect from the product?

Reading these summaries on a regular basis arms you with wealth of insights. These can be used for informing prioritization and strategy decisions.

That’s all on how I drive user research to understand what to build and evaluate what we are building!

Understanding your users deeply and knowing what they want is a superpower indeed.

User research helps you consistently build the right things and solve the right user problems.

So, If you want to start getting things right, its time to get talking and researching.

Additional Reading

• https://www.userinterviews.com/blog/usability-testing-best-practices?
• https://www.nngroup.com/articles/thematic-analysis/
• https://dovetail.com/blog/the-qualitative-research-process-end-to-end/

How to do user research effectively as a busy product manager was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Product roadmap is a planning document that highlights the goals and capabilities you will focus on in the next 6–12 months.

Roadmap planning is one of the highest leverage tasks which a PM does. Its a high risk, high reward responsibility.

After going through multiple product planning cycles, I have been fortunate to gain some insights into the building of product roadmaps.

This article is my attempt to share those lessons.

Why do product roadmaps fail?

In my experience, roadmaps prove ineffective because of the following reasons.

• More than half of the things don’t get delivered — At the time of planning, a magnificent picture is created which sets very high expectations. But most of the times, even 50% of the items don’t get delivered.
• Ignore the bigger picture and focused only on features— Lot of times, the roadmap appears to be a “To Do” list of disconnected features. There is little clarity on why the features are important, what metrics will they move and how will they help the business win among the sea of competitors.
• Inaccessible— Many employees don’t have any clue on what’s coming up in the product roadmap.
• Rigid —Priorities keep on changing due to new customer requests and market trends. However, nobody updates the roadmap and it remains static. The document thus loses its relevance.

Do roadmaps really matter?

It might seem like product managers spend a lot of time building roadmaps but don’t eventually use them.

However, in my experience roadmaps are crucial documents and one can ignore them only at their peril. Here’s how different teams benefit from it.

• Product team — It acts as a guiding light for them and helps them stay course on the most important priorities. Without this there would be utter chaos. Sales, support and the leadership will keep on coming with new requests every week and expect the team to prioritize it.
• Engineering team — It gives an idea to the team on what they will be working on and generates excitement.
• Sales team — They use the roadmap while talking to prospects and swing deals in their favor. (Caution: Sales team should not commit exact timelines for items mentioned in the roadmap without talking to product)
• Account Management team — They can create a pitch deck of the roadmap items and present to existing customers. It increases the likelihood of renewal.

So, roadmap is valuable for multiple teams.

Now that we know the importance of roadmaps for multiple teams and why they end up being ineffective, here are my two cents on how you can make make your roadmaps effective.

Steps to build an effective roadmap

Here are the steps you can follow while building the product roadmap.

1. Get clarity on the product strategy

Product strategy doesn’t mean having a ten pager document or some fancy deck.

For roadmap building, having a product strategy means the ability to articulate answers to following questions:

• What does your product do? (key benefit/value proposition)
• Who is it for? (target customer segment)
• What is your reason to win? (why should your product be preferred over other solutions in the market)

Knowing answers to these questions helps you prioritize the right user problems to solve.

If you use the product strategy to build the roadmap, its also easier to get buy in from the leadership.

2. Get clarity on the business goals

For the upcoming quarter or year, what are the business goals and objectives that your company is focusing on.

Some examples of business goals could be — customer retention, customer acquisition, reduce operational costs, diversify revenue through multiple products etc.

Your business goals might change over a period of time. For example — a early stage startup might have “customer acquisition” as its primary goal. But as it starts to mature, it might want to focus on “customer retention” to avoid the leaky bucket problem.

Knowing what business goals that matter in a planning cycle, helps you prioritize the relevant capabilities.

3. Identify the product goals/objectives

Product goals refer to the specific and measurable outcomes expected from your product. Every product goal should help achieve one or more business goals.

Some examples could be — improve the ‘ease of use’ of the product, increase the product reliability, make the product more customizable etc.

Its important to get alignment on the product goals and business goals with the stakeholders. Unless that happens, it won’t be possible to get alignment on the features to be prioritized.

The strategic objectives for the product can also be referred to as the ‘themes’ for your product.

For example — for a messaging app like WhatsApp, themes could be reliability, privacy, payments, video calling, chat engagement, AI etc.

The key product goals or themes can either come from a

• Top Down approach — Look at the market trends and your business goals to identify what goals should your product focus on. (This helps build ‘differentiated’ capabilities in the product)
• Bottom Up approach — Look at the product backlog and see if if there are certain trends which can be used to group the feedback coming from customers. (Focusing on these helps resolve the ‘customer pain’ points)

Identify the objectives by a combination of the bottom up and top down approach. This helps win you balance the roadmap with ‘customer delighters’ and ‘feature requests’.

4. List the initiatives/features that help achieve the product goals

After you have done all the above, you can start listing down the features that will help you achieve the respective product goal.

The benefit of this approach is that features are not listed in isolation. Every feature maps to a specific business goal and product goal.

If relevant, then highlight the customer problem being solved by the feature.

5. Prioritize the features

The last step in the roadmap planning process is to prioritize the capabilities to build.

I would suggest considering two factors to make the prioritization decision — Impact and Effort.

Both factors are subjective. So, don’t be too rigid on assigning exact scores.

Assigning effort is difficult as you don’t have the exact solution. Work with the development team to come up with a T-shirt estimate (Small, Medium, Large, Very Large)

For understanding the business impact, write down the evidence in favor of building the feature. This could be names of specific customers who requested it, relevant data points, whether all your major competitors have it or your articulation on why you feel the feature is important.

After this, begin discussions with the leadership to incorporate their point of view on the items listed in the roadmap.

After the internal discussions, you will be in a good position to determine what are the most important features in the roadmap.

Key Points to remember

• Roadmap planning should always be preceded with the formulation of product strategy — That’s how you lay the foundation for a building a compelling roadmap.

• Always be collecting evidence/customer quotes for user problems and product ideas — This makes it easier to take a call on prioritisation during the roadmap planning phase.
• Make roadmap planning a consultative process — First, focus on aligning the leadership on business objectives and product goals. Once there is alignment on that, work to drive alignment on the features to be prioritized.
• Make your roadmap easy to understand — Your roadmap should give clarity on the business goals, product goals and the features that are being prioritized.
• Avoid giving exact delivery dates in the roadmap — Roadmap documents should only give a rough guidance on when something is expected (for eg. Q2 2024, Q3 2024). Anything more specific than that, will put unecessary pressure on the tech team to deliver according to unrealistic timelines.
• Revise your roadmap based on changing product strategy — For eg. if you start building ‘AI’ features, then your roadmap should reflect the changing realities. Otherwise, roadmap would lose its relevance as a source of truth.
• Don’t cram the roadmap with too many items — Creating unrealistic expectations sets you up for failure. In fact, atleast 30% of the team’s bandwidth would usually go in fixing bugs, resolving production issues and fixing tech debt. Make sure you account for that in your roadmap planning.

Roadmaps can be powerful tools to inform, align and inspire your co-workers. Make sure you craft them using a rigorous, structured and consultative process.

Further Reading on Roadmaps

• https://medium.com/agileinsider/prioritising-the-right-feature-set-using-theme-based-roadmapping-6afa0f39a60e
• https://www.romanpichler.com/blog/product-roadmapping-mistakes-to-avoid/
• https://www.linkedin.com/pulse/product-roadmap-should-you-build-one-all-steve-johnson/
• https://www.productplan.com/learn/what-is-a-product-roadmap/

How to build effective product roadmaps was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Its rare that your boss asks you to build something and you respond with — I would not recommend building this now.

But the day you do this, you become a badass product manager — because you have finally developed a spine and learnt the art of saying NO.

So, let’s revisit one of those days from my life.

One afternoon, my boss messaged me and said — “Let’s build this feature*.”

*The feature was about automating one of the product workflows. Every time a customer had to use this workflow, they had to reach out to the support team and get it enabled manually.

My boss had a strong argument in favor of building the workflow.

The workflow was used by our biggest customer (contributing approximately 15% to our revenue), who now wanted to automate this workflow rather than rely on support.

But I didn’t yield immediately.

I borrowed some time and spent a few hours researching about the request.

This is what my research yielded.

1. The customer had just renewed. So, they were not a churn risk.

2. Developing the automation was not straightforward — It would require about 3 weeks of development and testing effort.

3. There were hardly 4–5 customers who were using the workflow. So automating the workflow was not expected to benefit many customers.

Based on this, I went to my boss and said those magical words.

I would recommend not to prioritize this feature.

We had a brief discussion and my boss agreed with my assessment.

And that’s how I became a badass PM by learning to say no and avoiding to build a feature that wouldn’t generate much business ROI.

Obviously, not all “don’t build this” recommendations are accepted so easily.

There will be times when the “don’t build this” recommendation will ignite furious debate. Your recommendation might be rejected. And, as they say at Amazon, you would have to disagree and commit.

But whether the recommendation is accepted or not is beside the point. What matters is — whether you debate ad-hoc feature requests or do you meekly submit.

Learning the art of saying no will help your team minimize distractions and ship faster.

Why might you be hesitant in saying NO to a feature request from the boss?

1. You think your boss would get angry if you say no —Well, If the feature doesn’t do well they will get angry anyway. So, better risk their wrath early on.
2. It’s a small request and we should just do it — That’s a terrible justification. If its a meaningful request, then do it by all means. But not because its a “small request”.
3. Building the feature might be a good idea — That’s a lazy argument to wiggle out of a discussion. Spend some time gathering evidence before forming an opinion on whether the feature is a good idea or not.

Steps to deal with an ad-hoc feature request

1. Understand the rationale behind the request

• Don’t just focus on the “what”. Understand the “why” behind the request.
• Is the request directly coming from the customer or is it a “cool idea” from the boss?
• What makes your boss convinced that this should be built now?
• Does the request align with the company’s strategy and target customer segment?

2. Understand the possible solutions to the problem

Your boss doesn’t want a feature. They want to solve a problem. There could be simpler ways to solve the problem. Or there could be workarounds to partially solve the problem.

• Have you given a thought to the workarounds that could be implemented without much development effort?
• Have you explored solutions to this problem in the past? What was the conclusion?

3. Get a better understanding of the business impact and development effort involved

• Dig into past data to see if customers have asked for the feature or reported the underlying problem.
• Check with your support or sales team to know whether a similar feature has been asked in the past?
• Discuss with development team(s) on the complexity of building the feature.

If you do the above diligently, you will have sufficient details to frame an opinion about the urgency of the feature. Take a decision based on what you think is in the long-term interests of the company.

Finally, its time to go back with a recommendation to your boss.

Crafting the response

It’s not what you say. Its how you say it.

Use the evidence gathered to decide whether the feature should be build now or not.

If you are giving a “don’t do this” recommendation, avoid the following mistakes.

• Not giving solid evidence to back your claim — You can’t reason with the boss on the basis of opinions. They will always find a way to shoot you down. So, make sure you have a data backed or customer research backed opinion.
• Hurting the boss’ ego by making it personal — Nobody likes to hear a “No” for the work they assign.

1. Use your words carefully — For eg. I use a phrase like “I would recommend not to prioritize it” to show who is in charge.
2. Voice disagreement with the boss in private — If a request is made publicly and I am leaning towards rejecting it, I would engage in a private conversation with the boss and share my reasoning with them.

• Not highlight the opportunity cost of building the feature — If the boss is adamant on prioritising something, highlight what project(s) you will de-prioritize in order to fulfill the request. Leadership is often unaware that the development team is already packed with tasks and its a question of “whether this or that”.

Once you give a “don’t do this” recommendation, it will likely spark a spirited discussion. Don’t be afraid of that. State your points gracefully and respectfully. This way, whatever decision you arrive at, will be in the best interests of the company.

Remember: There may be many reasons to build a feature but “just because the boss said so” should never be one of them.

References

• https://builtin.com/articles/saying-no

Learning to say NO to adhoc feature requests as a product manager was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The only thing constant in a PM’s ‘dynamic life’ is delay in delivery commitments. What starts off with “Yes we can” at the start of the sprint, quickly turns into “Umm we can’t” towards the end of the sprint. Its quite amazing how the same script plays out with remarkable consistency during each sprint.

In my experience, following are the major reasons for delays:

• Lack of stakeholder buy in at the start of the project — So, midway during the project, the differences among different stakeholders rear their ugly head and lead to delays.
• Complex implementation logic — Some projects are technically complex to implement. When there are multiple unknowns, the delivery estimates given by the tech team often turn out to be wrong.
• Important edge cases getting missed — PRDs without proper documentation of the various scenarios and edge cases lead to a lot of back & forth between the PM and the development team.
• Shifting priorities — When the tech team is forced to simultaneously jump between multiple projects, it hampers their productivity.
• Scope creep — While a project is in progress, if new requirements keep pouring on the development team, you can forget all about timely deliveries.
• Communication Gaps — During the project, lot of smaller decisions are taken regarding the user experience and behavour in various scenarios. When these are not properly documented, there is gap in understanding of the product, development and QA teams. It leads to back & forth and delivery delays.

Shipping velocity has a big role to play in determining your success as a product manager. Especially for startups, shipping velocity can often be the difference between winning and losing customers.

As a PM, its important to ensure that you are making constant efforts to ship quality output as fast as possible.

Here are some tactics that have proved helpful for me.

1. Getting engineering, design and product leadership looped in from the start — I have observed that whenever the leadership gets involved late, it leads to rework. They may not be satisfied with the design or the architecture or the scope of the problem — so better to involve them at the start and proceed with their stamp of approval.
2. Defining the scope before development starts —Defining the scope means means giving clarity to development team on the problem we are solving and the proposed solution. If you are unsure about the scope, spend a few more days getting validation from customers rather than rush for development to begin. (If new details emerge later, either be okay with delaying the release or bring down the release into versions)
3. Share designs early and get everyone’s feedback before development begins— Giving multiple team members a walkthrough of the designs helps bring forth obvious gaps and poorly designed workflows. These discussions ensure that there is a lesser probability for back & forth later on.
4. For complex technical projects, define milestones and rely on POCs/prototypes— When we take on complex technical projects, visible progress is often slow. They might take months to get shipped. This could create the impression that the PM is not proactive. So, better to work with the tech team to build a rough prototype and test it out with the relevant stakeholders.
5. Write a comprehensive PRD which has the edge cases and behaviour in different scenarios detailed out —You can use checklists to ensure that you don’t miss out on important scenarios while writing the PRD.
6. Don’t make your development team jump between different features — Allow your team to focus on one feature at a time rather than changing priorities every week. Changing priorities is the sure shot way of delaying delivery. If priority changes come from the top, make sure you inform the leadership of what gets delayed when they try to ship in that “one urgent request”.
7. Always get the development team to share timelines — Getting timelines creates a sense of urgency and accountability. Even if timelines are missed, you can use these misses to push the team to move faster. are able to fix accountability. Without timelines, nobody understands the urgency of a project and things move at their own pace.
8. Regular progress check-ins through standups — Progress check-ins help in proactively identifying situations where developers are stuck or a team member is slacking. (Some people just won’t inform that they are stuck unless you explicitly ask them the status of the project).
9. Proactively update the PRD with any changes — Update the design files and PRD with any change that was finalised during the development process. This keeps all team members in the loop and reduces delays at the time of testing.
10. Keep the entire team informed about the project status — Have a common forum where questions related to the project can be asked and daily updates can be posted. Publicly communicating all these things from the start minimizes chances of surprises later on.

As a PM, your list of projects will be long and time will be short. So, being able to scope down projects and ship them fast can be a superpower that will help you stand out in your organization.

References

• https://blackboxofpm.com/the-time-value-of-shipping-6deaf8d7d565

How can PMs ship features faster was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Product or feature redesigns is an initiative which most product managers undertake at some or the other stage of their career.

Product redesigns are undertaken usually due to the following reasons:

• De-clutter the UI — which has become complex due to addition of too many features
• Simplify the user experience — by improving discoverability of key functionalities and/or adopting standard design patterns.
• Adapt to new industry trends or respond to competition

I have been a part of multiple redesigns over the past couple years. Some have been successful and some have received customer backlash.

Here are my leanings on improving chances of success while re-designing products or features

Design and Development Phase

• Start with a clear “why” behind the re-design — Companies often initiate a re-design simply because there’s a new leader in charge. Re-designs without any kind of qualitative backing end up being a waste of time and resources. Screens where there is prior user feedback around complexity can be the initial candidates for redesign. For any redesign, you should be able to articulate— why do we need this re-design and why is it important to do this now?
• Understand the user journey — As part of the re-design, one or more user facing screens change. Identify the key actions user expects to perform when they land on this screen.
• Have a solid review process to evaluate the new designs — Get the designs reviewed with QA and support teams. They can highlight issues from a customer perspective. If something is flagged by multiple people, treat it as a red flag and try to incorporate the fix for that.
• Build for the future — A common reason for redesigns is to reduce the clutter in the UI because all the features are not fitting in properly. Make sure you anticipate the features that are likely to come in the next 6–8 months, so that you don’t have to repeat the redesign exercise after a month.

Launch Phase

• Dogfooding the changes before launch — Never release redesigns without letting internal teams test it first. This helps expose obvious gaps in the solution.
• Limited rollout — In case of major redesigns, release the feature to a subset of customers before making it generally available to all customers. This helps gather user sentiment in a controlled environment and act on critical feedback.
• Let users try out the new design — It can be useful to let users manually opt-in to the new design. For some time, users can be given the option to choose between the new design and old design.
• Inform internal teams about upcoming changes so that they can handle customer queries and update the training material.
• Advance Communication to customers before launch— Eventually, you will have to make the re-design live for all the customers. If the changes affect a core customer workflow or lead to significant user anxiety, its a good idea to inform customers of the upcoming changes. This way, they are not in for rude shock due to sudden rollout of the changes.
• Use in-app messages and contextual tips to inform users about what’s changing and how will it benefit them — To soften the anxiety of learning something new, its useful to highlight the benefits of it.

Redesigns are a tough nut to crack.

From a customer perspective, a redesign is like being transported to a new house overnight. Everything around you suddenly changes. You now have to learn afresh how to perform those actions which had become part of your muscle memory.

As product managers and designers, its our job to make the entire process of adapting to the redesign as seamless as possible for the end user.

References

• https://www.chameleon.io/blog/product-redesign
• Success of Gmail Redesign: https://www.eleken.co/blog-posts/gmail-redesign
• Slack redesign: https://www.theverge.com/2023/8/9/23824562/slack-redesign-app-dms-activity-later

How to reduce chances of failure in case of product redesign was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week, I attended a webinar organised by Toplyne on the Psych Framework. It was conducted by Darius Contractor, who has led growth at Dropbox, Facebook and conceptualized the Psych framework for driving user growth through user psychology.

Q — What is Psych?

Psych is a unit of measurement of user motivation. Psych score will vary from 0 to 100.
Whenever a user visits a website, they encounter different elements on the website. These elements can either add to the user motivation, thereby increasing the psych score. Or these elements can reduce user motivation (by creating friction or confusing user), thereby reducing the psych score.

The goal of a website should be to maximise the psych score for the user by increasing elements that add to the psych score and reducing elements that reduce psych score.

Q — Does the user have a starting psych?

Whenever a user visits a website, they have a starting psych. This is determined by how important the product is to them and how they landed on it.
For example, users landing on a dating site via Google search have a very high intrinsic motivation as they are explicitly searching for dating.
On the other hand, if user clicks on an Ad on a third party website and land on a website without clear messaging, they will have low motivation and are likely to drop off.

Q — Which elements add to your psych score and which ones remove from your psych score?

If we consider the landing page of a website, here are the different elements that could add or reduce psych.
+Psych factors: Social proof (logos, testimonials), clear action oriented layout, high quality images, clear messaging
-Psych factors: low quality images, crowded layout, unclear next steps etc

Conclusion

Psych is a useful framework for understanding how the user’s emotional energy changes as they browse through your product or website.
Focusing on things that add to this emotional energy can help build us products that have a higher conversion rate.

Further reading Material

• https://andrewchen.com/psychd-funnel-conversion/