Product Management

What does being data driven actually mean?

July 15, 2021 by Sohaib Leave a Comment

I hear this quite often, from friends that work at companies that say they are data driven, and while i am sure they believe it, in many cases upon chatting for some more time I realize that many don’t fully understand what being driven by data truly means and entails, here are a few points on how an organisation can be really driven by data.

I also realized while exploring this topic with these friends, some of which own tech startups, that the value of making decisions based on insights and data is often missed, so before I detail a few aspects of how to be data driven, let me take a step back and explain why taking decisions based on data is actually important.

What differentiates successful tech companies from the others?

I would argue that its how they collect their data, validate it and use it in their decision making process, usually at the product team level and all the way up to their leadership team, often in these companies, relying on data to make decisions is part of the company’s DNA.

The ability to derive insights from the data you collect is what really differentiates these companies, they have mastered tools and processes that facilitate access across all layers of the business to the data they collect, PM’s, engineers, UX/UI, copy writers, customer service and commercial teams have access to all of the data that is available (with proper regulatory and permissions management to ensure compliance with things like GDPR), and they usually have dedicated team members or a complete department to validate and store this data and ensure stability and accessibility.

A recent Forrester research indicates that advanced insights-driven businesses are 2.8 times more likely to report double-digit year-over-year growth. And 31% of advanced businesses say that their ability to drive new revenue streams is a primary benefit of using data, versus 17% of beginners.

So here are a few main points you need to take into consideration and reflect upon to see if you are a data driven organisation

Interpretation of changes in user behavior

Lets give a simple example to elaborate, lets say you’re using google analytics to track behavioural user metrics across the check out process in your product, often this is seen as one of the basic steps of data collection, a product manager of this product or area of the product would normally check this data often to see if anything changes, others in the business such as LT and sales might check it as well.

At some point, a change is seen in this data and reasons as to why this change might have happened are made, and sometimes solutions or changes based on this data are generated or implemented, and because these changes were done based on this change in the data, this team or company thinks they are basing that decision on data.

In reality this scenario of using data is just scratching the surface, product teams here fall into the trap of assuming their reasons for explaining this change are valid, and often don’t validate these assumptions, approaching every assumption as a hypothesis needs to be part of the DNA across the business and all assumptions should be validated either by other quant. data if available or by qual. data or both (even better).

Do you trust the data you have?

Many focus on collecting as much data as possible without thinking of how do we make use of this data? how do we store it and maintain its accessibility and what are the definitions that we need to have within the business to be able to use this data. The end of objective is to become an insight driven business, many business collect allot of data but continue to make decisions based on everything other than the data.

So first things first, you need to trust the data that you have, and define metrics/KPI’s that matter to your business based on this data, make this data accessible to every layer in your organisation and make sure tools to visualise and see this data are available for product teams, skip beyond vanity metrics and focus on metrics that drive your business. Grafana is a powerful open source data visualisation platform.

Data is subjective

Someone will always decide what data to collect, how to collect it and how to store it, all of these decisions play a factor in determining how useful that data is, so you always need to ask yourself, where does this data come from? and why was it gathered and presented.

Empowering everyone to take decisions

Now comes the harder part, once you’ve collected data that you trust, made is accessible and monitor-able, the hardest part is actually empowering your product teams and individuals to make decisions based off of this data, empowering these teams to innovate without having to go allot of red tape while addressing risks that come with such empowerment.

This empowerment is all about fostering innovation and making independent decisions, and is less about pushing down ideas and decisions from leadership & management on to teams to just implement.

The decisions product teams make should be visible and accessible by the organisation, to foster accountability and collaboration.

Validation doesn’t limit you

Some consider making decision based on data in the form of an A/B test limiting to their freedom or their creativity, which is quite strange when you think about it, how is validating your idea with data limiting? to me I don’t see how you would do product development in any other way…

A/B testing should be at the core of developing features

Empowering your teams with the ability to experiment (with A/B tests) and test their hypothesis should be the heart of your strategy, validating new features and ideas through A/B tests should be the only way to roll out a new feature, something that is much easier now than it was 10 or 15 years ago, there is an array of tools that allow you to get started with a relatively small investment.

For the sake of keeping this post short I will skip going into detail about A/B testing and leave that for another post and another day.

Where do ideas come from ?

November 8, 2020 by Sohaib Leave a Comment

One of the most important tasks, and often what is occupying a good part of the thinking of a PM is, what should we build next? a simple question but one that carries with it allot of details as to what usually goes into this process and how good PM’s source and priotorize ideas, for the context of this post I will focus on where do ideas comes from, prioritizing them will be a subject of a future post.

There are some differences of where ideas come from and their importance depending on what type of a PM you are and to what type of product,, there 3 main types of PM or products in the tech. space:

Consumer products or B2C products (think of instagram, snapchat)
B2B products (think of SAP, AliBaba)
Internal products (think of customer service tools)

Lets start with the common sources of ideas and add the specific cases for the 2nd and 3rd types of products, one thing to keep in mind, is that its very rare for you as a new PM to start off with a clean slate/no backlog that already exists, in most cases you would be owning a product that exists with a backlog of ideas that you need to understand and priotorize.

Employees and colleagues

The first source of ideas are employees in the business, these include your team members, PM’s of teams working in the same business area/unit, your manager, leadership team, or CEO, depending on the size of the business these titles will change but they all fall under this category. Also researchers and analysis’s are a valuable source of “high quality” ideas as its usually coming from a qualitative or quantitative source which saves you a bit of time in validating it, but it still needs to be prioritized (more on that later)

Customers

Customers can tell you things in two ways:

Directly, as in from feedback forms, customer service tickets/issues and calls, these are usually bugs or issues but can also uncover user needs and features improvements or new features that could be built.
In-directly, this happens from metrics, your users can be telling you something, a problem they are facing (exits from a funnel, high bounce rates for example) or something missing they are looking for (high churn rates for example can indicate missing value proposition), a good PM hunts for these signals in the myriad of data sources they have at their disposal, finding such signals usually requires a deeper look, might include implementing a survey, feedback form or follow up emails to gather more details as to why a user has left the product.

In a B2C product, the above cover the main areas where PM’s gather and generate ideas that need to be vetted, sized (business impact and effort) and then prioritized. There are many techniques to generate ideas with your team such as design sprints and brainstorms where you would combine your insights and use these frameworks to help come up with new/innovative ideas.

There are however, other sources of ideas that are more common in the B2B and internal products.

Sales or Clients in B2B products

in a B2B business, there are usually less users of the product but these users have a much stronger influence on the product, in many organization sales represent the clients and PM have to work with sales to understand what clients need, working directly with clients or users of the software in SAAS business for example is usually best to capture what their needs and pain points are.

There are many commonalities to B2C products in how PM’s should go about validating these needs, but the main difference is that in B2C you usually have hundreds of thousands or millions of users while in B2B its a much smaller number.

Users of internal products

If you are a PM for an internal tool, then your main source of ideas are the users of the tool, depending on how many users the tool has, your methods of collecting these ideas would differ, but managing an internal product is usually very different than a B2C product, you usually will not be able to experiment (A/B tests) for internal products as you would never get the statistical power needed, as such you will have to rely on proper understanding and capturing of the user needs and making sure the product delivers on their needs efficiently, objectives usually resolve around efficient usage, time saving of the users and adoption. (this of course can be very different depending on the product but this is what I have seen in my previous experiences)

I hope you found this useful, there is much more to discuss in each of these categories that I hope I can cover in a future post or podcast.

As always, stay safe, and stay wild!

How to efficiently utilize OKR’s

October 10, 2020 by Sohaib Leave a Comment

Using OKR’s gives your team the guidance its needs each quarter

OKR’s (Objectives and Key Results) are a framework to manage your company, department and team objectives for the short term (usually quarterly) and long term (1 year) efficiently.

This framework is widely adopted at many of the top tech companies and I have been using it to manage my team’s objectives for the past 3 years. And during the course of implementing it, using it and learning how to better utilize it, I learned a few things that I would like to share.

I will be writing another post soon to introduce and explain the basics on how to set them up properly. but in this post I am sort of jumping to a more advanced topic.

The culture

Make no mistake about it, depending on your company’s current culture, OKR’s is anywhere in between a small improvement or modification to your company’s culture, or a big cultural change and in most cases its probably something in between, which also means its a change that needs time!

The benefit of such changes take time and knowing this beforehand helps set the right expectations and allows everyone to be comfortable with experimenting and trying it without the fear of doing a mistake, team’s will have to get used to the monthly review cadence, get familiar with sizing their opportunities or main streams of work that will deliver on their key results.

Opportunity sizing

I sort of touched on this earlier, teams need to be able to first think outcomes not outputs, meaning, what is the outcome or business impact expected from the work that the team will be doing ? usually in terms of KPI’s and metrics that will improve based on this work, once figured out, they will need to roughly estimate and size what is expected as an outcome of the work they planned to.

This is not easy, the more experienced the team is with the product, customer and market the more likely they will be able to come up with realistic targets and their moon shots, if its a new product area this will be more difficult but still doable, in many cases we had to run AA experiments to measure traffic, baselines of our primary and secondary metrics, and then combined with qualitative and quantitative analysis, we were able to set good targets for our selves that were not too hard to achieve nor easy to accomplish.

Peer team reviews

A healthy culture of peer feedback is priceless, where co-workers can review and offer feedback on OKR’s of other teams is very useful and offers a number of benefits:

Makes sure team’s are aware of what others are doing in their track/department, this eases communication and uncovers opportunities to collaborate or, in some cases, highlights potential areas of conflict.
Shared learnings, in many cases other team’s might have tried or have run across team’s trying to achieve similar objectives and might be able to share insights that can inform the product discovery or delivery.
Creates transparency, when knowing what are other team’s targets and objectives, how are they progressing towards their goals, it also sorts of creates a healthy competition and inspires learnings, especially when team’s share their learnings (on successes and failures)

Shared Learnings

Also hinted at this earlier, it is important IMO, for team’s to share their learnings at the end of each month, in any format, it can be a slide, a presentation team’s deliver, or a post on the company’s internal network, this creates a culture of ownership and collaboration, its important to emphasize sharing both successes and failures, we learn allot from both, and as long as we look at both as learnings, team’s and individuals will not be afraid to speak up and try new things, all critical for an innovative environment.

That’s all for this post, hope you’ve enjoyed and found it useful, if you did, please share it and subscribe to my newsletter to get the latest of my posts, videos and live streams!

Stay safe, stay wild!

What is product management?

September 19, 2020 by Sohaib Leave a Comment

Product management is often misunderstood or confused with other job functions and crafts, in this post, I will explain what do people mean when they mention someone that works as a product manager or a job opportunity in this field.

In many cases, especially in technology companies, product management or a product manager refers to the person responsible for the vision and strategy of an entire product or part of it, depending on the product’s size and scale that is.

A product manager in a tech. company work with a group of engineers, 1 or more UX designers, copy writers, product marketing managers and some times data scientists to deliver on the product’s vision and roadmap, which is something this same team is usually responsible for creating and driving.

Modern product management is very much different than traditional product managers that in older companies used to be someone implementing what marketing, leadership or others agree on and the product manager is expected to execute, in most cases in water fall setup, or an agile/scrum setup, in both cases, in that setup the product manager is responsible for the delivery of the product only, which is NOT what we are interested in.

Product management is also not project management, both are very different, while a project manager in mostly responsible for the planning the timelines, budget and communications, which is somewhat shared with the product manager, a project manager has nothing to do with the vision of the product, what it is intended to solve, what customer pain points it addresses and how does it help the company succeed.

Finally a product manager is not a manager of people, he/she is a manager/owner of the product, they are responsible for its success or failure, the team that the product manager works with develops the product that they all believe will fix the customer’s problems or deliver the customer its intended value, the success is theirs to celebrate but the failure is the product manager’s responsbility.

In future posts I will be explaining more about what does this job require, how to get into this career path, share a bit of my personal experiences that I hope will be useful in explaining this profession more.

Until next time, take care!