A Guide to Data Science Product Teams Workflow:

A Product team’s goal is to deliver value quickly to customers. Finding out what will deliver the greatest value (aka “Discovery”) is followed by building and delivering it (aka “Delivery”). Both of these processes rely heavily on data science.

Discovery:

Abstractly, it’s obvious how data can aid discovery. Many industry leaders talk about “using data” to validate customer needs. Even when interviewing very senior PM candidates, I see them struggling with questions such as “if you had access to any data in the world, what would you want to know to inform your direction?

Without a skilled data partner, your product teams are more likely to fall into a variety of pitfalls, ranging from the mundane to the existential:

• The wrong (inaccurate, outdated, incomplete, etc.) tables are used to inform decisions.
• The path to answering a question that could have been handled quite simply and elegantly is quite challenging.
• The process of testing hypotheses using adjacent or incomplete questions to verify them.
• Establishing faulty hypotheses that cannot be tested.
• Ignore ideas that might lead to new ideas.

Delivery:

Delivery is about execution craft and velocity, and unless you’re building a data-model-backed feature, you don’t need to be involved in the process.

Velocity is the most critical factor in the delivery phase. A major obstacle to speed is the uncertainty that culminates in thrashing.

Every member of your team — and likely every senior stakeholder in the organization — will ask these questions during delivery. Unfortunately, there is no definitive answer. It’s impossible to know for sure.

In these moments, you have three pillars you can lean on:

• Personal opinion: Applicable to some extent — this is why we hire seasoned practitioners! But it’s hard to win a tie-break when peers disagree.
• User research: Valuable if you consider the question during discovery. It usually takes too long if you uncover a new question mid-flight.
• Data: Fast enough to validate further questions as they arise.

Amid delivery, someone may ask, “how do we know this is right?” If you considered whether that question was relevant during discovery, you likely have user research or discovery data to draw from. Clarity can be achieved with the involvement of skilled data partners.

It would help if you acted quickly. If your team’s trust in the project has diminished, you will have difficulty getting back into the groove. With a data partner on-hand and in-context, delivery can be kept moving in magical ways.

Where to Integrate: Project Cycle and Product Cycle:

We have talked about data partners assisting with both Discovery and Delivery, so let’s discuss how product teams handle those activities. 

Project cycle: Driven by the feature. Every feature will be followed by a more-or-less templatized project cycle (whether it is shipped or not). This is where product teams spend the most time.

Product cycle: Driven by the team mission. The product cycle surrounds the project cycle. This is often amorphous, poorly understood, and rarely formally documented. Product teams add the most value in this area.

The Project Cycle:

Most product-driven organizations have a system for this that is fairly well understood and documented. The idea cycle describes how ideas progress from exploration to validation, build-out, launch, and evaluation.

Data in the project cycle begins with a deep understanding of how the cycle works at your company and on the specific teams you work with every day. The documented process is usually an amalgamation of all the steps that various product teams take during their project cycles. Identify where your team skips bits here and there.

Make sure you’re contributing effectively once you know how your team gets things done.

Discovery:

• – Looking for examples of customer pain and workarounds in products
• – Hypotheses are developed and evaluated
• – Informing engineering direction with small questions
• – Recommending A/B test structure (if needed)

Delivery:

• – Reducing ambiguity when new questions arise
• – Making edge case tradeoffs based on data
• – Instrumenting usage data in the right way and reviewing it
• – Setting up and evaluating the results of a test

Product Cycle:

Product team members are prone to recording or displaying themselves. Managers often lead them. During this phase, the product head can provide the team with ideas and priorities. For some businesses, the sales department is the driving force. For others, marketing is the driving force. Each organization combines these elements differently.

In any event, the product manager has a good idea–one of their major tasks is to keep that product’s cycle in line and focused on positive outcomes.

As a data provider, the greatest leverage you can use is in changing the cycle. In this case, you’ll be doing things such as:

• Analyzing the results of multiple A/B tests to determine how the team can proceed in the future.
• First-order insights derived through recent data anomalies, or emerging developments in data about customers
• Consider what problems we can discover with our existing information and logs
• Indicating when the team’s orientation and ethos are not aligned with the information about usage

Each is incredibly high leverage, yet they take an enormous amount of effort, time, and imagination to build. It also takes lots of effort, time, and vision to implement, and therefore don’t expect to make a difference each time you ask. It requires patience and perseverance to pay off when executed with care.

Be careful when dealing with subtle dynamics that influence the process of product development. It might take some time to create the proper context to be able to influence the process. Also, remember to establish credibility and give the team to increase the quality of aspects of the project.

You’ll be a huge asset to the organization once you get the hang of contributing to both product and project cycles.

https://www.suryasys.com/you-need-these-8-skills-to-be-a-good-data-scientist/