Survival Guide to a Data-Oriented Product Management

“Data is the new oil.” This quote has riddled my mind since the first time I read it. It is from Clive Humby, a mathematician and Tesco mastermind. If you work in the data market, you probably already heard it somewhere.

To understand why it’s so valuable, I believe it seems like a wormhole – like the ones seen in space movies – since data can give you the power to access the best resources in a shorter time, give you the ability to make informed decisions, find solutions to problems, be strategic in your approaches skipping the guessing game with raising based arguments and a lot further. How much is your time worth?

Splunk Inc. (NASDAQ: SPLK) announced in 2020 the research which explores the correlation between the company’s use of data and its business success. The study was done among 1350 senior business and IT decision-makers across industries in Australia, China, France, Germany, Japan, the UK, and the US.

The result is not surprising; the giant investor in data innovation is the technology and financial industries.

Data Deliberator: Early phase of their data strategy implementation.

Data Adopter: Organizations are making good use of their data but still have room for improvement.

Data Innovator: Organizations with the most vital strategic emphasis on data have an advanced strategy to extract business value.

But, how to start to guide my company to be data-driven? The first thing is the organization’s mindset.

The main goal of engaging your digital customer is to directly offer them unique and personalized experiences through digital self-service solutions or empower business areas to reach the same objective through faster and more accurate decisions. To achieve it, you will need to look to the IT department as a business area that can unlock new business opportunities, not as an operational support area, and it’s the most critical time to avoid scope misunderstanding. 

It is possible to gain insight into three fundamental pillars to do it. We can walk through the hierarchy: Strategic, Tactic, and Operational. Yes, it needs to be top-down.

Strategic

Drop this discussion on the C-level table. Is the company prepared for digital transformation?
The IT department will act cross-company, so everyone must be prepared for the coming changes, and, from now, all the IT teams (current or your intention to hire) need to have their product vision and mission intercompany. Staying aware of the organization’s direction is essential to set the professional’s profile involved in the objective.
Set priorities, project portfolio, budget, technologies, and deadlines in a matrix that allows you to measure the cost, risk, and impact. 

Tactical

Considering that you already have the portfolio, it’s time to look to the development team and create squads that can attack different problems but with some synergy between the type of job that needs to be done (governance, infrastructure, data engineering, data analytics, database, security, etc.).
For each team, establish:

• The objectives (what we do / what we don’t).
• Who are the stakeholders inside the internal client’s team (other developers, business analysts, managers, etc.) 
• The key results (OKRs) for each one, considering the team configuration and capacity.

So, it’s possible to create a timeline, and it’s time to get the hands dirty.

Operational

In the strategic lane phase, you figure out who your client is (in part, it can be yourself); in the tactical lane, you find what kind of job you can offer them. 

Now that the objectives are clear and you know how to do it, it’s time to set up the engine.

Each team will be responsible for handling some job, and the Product Owner should have a toolbox for these demands (remember that it was agreed upon in the past). 

• Alignment: Understanding that demand is a part of the team’s scope.
• Research: The demand can already be attended by another solution or another way that the user can join.
• MVP and Validation: The client should understand his responsibility in the homologation phase, and they need to know that it’s a process during the development with their participation.

The development work doesn’t end with the delivery; creating a value chain is necessary to ensure value and constant team improvement. We cannot forget that it’s our responsibility to provide the best product for our clients. The ITIL 4 Service Value Chain (SVS), promoted by AXELOS, framework suggests the following: 

Plan: With the team vision, you will build a product vision (it can be a service process with the same inputs and outputs) comprehensively understandable and transparent.
Engage: Your internal client and all stakeholders should know that they are part of the development process with definition and homologation responsibilities. 

Design and Transition: Ensure that the product will fit the user’s necessities, with a focus on solving their problem and user adherence.

Obtain/Build: It seems a lot with refinement. Ensure that you have all you need to build that solution into the necessary specifications. 

Deliver and Support: Even the product’s functionalities will suffer no changes at this point, is important to support the data pipeline and all the necessary resources to keep the product working. That’s one more reason to give value to having documentation. 

Improve: Set feedback cycles and retrospective meetings to have a 360 vision of how your team and clients see the solutions, and then, improve products, services, procedures, rituals, etc. 

Does it really work? 

The leadership team also has the responsibility to measure how things are going. There are some techniques that Scrum Masters learn and can help using a well-fit agile methodology that can be content for another exclusive article; beyond that, you need to check the OKRs and the KPIs to have a comprehensive view of the tangible and non-tangible goals.
A starting point to measure KPIs can be divided into three primary perspectives. 

• Compliance
  Decrease demands without the proper DoR.
  Decrease in emergency chances.
  Decrease unauthorized changes. 
• Effectiveness
  Increase in the percentage of changes implemented.
  Decrease in bugs and re-work.
  Decrease in failed changes.
• Efficiency
  Benefits gained.
  Average time to implement.
  Increase the percentage accuracy of changes estimate.

Bonus

If you have reached this point, I want to share that in the remote-work scenario, it is essential to establish meetings only with the necessary participants and have a very accurate agenda. Don’t be afraid to cancel meetings any longer necessary or end an appointment earlier than planned. 

Most developers’ pain points are a lack of clarity on requirements, inconsistent technologies, infrastructure issues, and other communications issues. These processes also aim to give transparency and inspire a safe workplace.