In a nutshell, Data Product Management teams are responsible for analyzing and implementing data product opportunities within an organization. When discussing successful data product management, many similar basic principles apply as with other technical product management initiatives. But there are some unique differences that you must understand to achieve the best results, such as:

  • Data products are usually components of other products, rather than being marketable on their own
  • They’re more likely to serve internal rather than external customers of the organization
  • Their key success metrics usually indicate value, not direct revenue or profit

These distinctions can help you identify impactful best practices or “rules” that Data Product Management teams should embrace.

Our first rule is an absolute must. In fact, if you don’t get this first one right, you might as well not even start:

1. Be clear on the business need and its associated value

It’s critical that your team is committing time and effort toward something that’s worth it. Extremely analytical people fill the Data science field. Sometimes, over-analysis can lead to an incredibly cool project that really isn’t going to deliver much value. Understanding the actual value of your product will keep your data product delivery team motivated from start to finish. By stating who will benefit and exactly what those benefits are, your entire product development lifecycle will focus. This also helps reinforce the specific value of your product when you deliver features to your customer. Specificity is key. A general or vague idea of the need will not serve the team or the customer.

Our next five rules really deal with how your team operates. From managing the team and the work to keeping the metrics of success clear at all times.

2. Fall in love with the problem – not the solution

This point comes from Marty Cagan’s book, Inspired, arguably the foremost reference for technical product managers. When a team “loves the problem”, they prioritize arriving at the simplest, most effective working solution, as quickly as possible. You need to make sure that quality standards are applied. As Cagan advises, falling in love with the problem keeps you from getting attached to a specific solution. This provides an advantage when there’s a better one right around the corner. Speed is of the essence here. No amount of “closed-door” testing can match valuable input from business users themselves. And, you’ll reach validation that much faster.

3. Keep all your work visible

It’s important to monitor your team. Nothing should be worked on that the Data Product Manager or Product Owner hasn’t included in the current Sprint. That includes functionality that’s not explicitly required to satisfy the Acceptance Criteria for Data Product Management. However, one exception to this rule is allowing time for the team to challenge the Acceptance Criteria. Especially if it’s vague, unclear, or it might not be enough to solve the customer’s problem. As you’re considering whether these conditions apply, remember the 12 Agile Principles articulated in the Agile Manifesto. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

4. Be the expert where it matters

You don’t have to master every feature or aspect of your product. Although, you better understand these points thoroughly: The customer AND their needs. The technology at hand. Particularly, when assessing any potential obstacles or risks and differentiating a good technical idea from a bad one. The data itself and all the data sources, tools, and methods for capturing, manipulating, and exposing it.

5. Assemble the right team

While no one disputes the value of having “data gurus” around, ultimately we’re still building software products. Strong data and software engineers are vital to success. Additionally, they become invaluable when they possess deep domain knowledge. Make sure someone on the team can implement and manage automated test practices. Hence, you don’t have to perform manual tests every time you make a change. A Product Architect is vital to ensure that the product’s design is on a solid footing. Sometimes the Data Product Manager will fulfill this role. Certainly don’t underestimate the value of having a second opinion here. On that note, embrace the idea from Agile Scrum that team members can play multiple roles. But, the delivered solution must check all the boxes for a reliable product AND meet its defined needs. To clarify, don’t give anyone (including you) more than they can handle in the time given.

6. Calculate the specific value of the Data Product

These products are usually part of a larger solution. Therefore, you must ensure you inherit customer requirements and other related products to serve. In addition, you need to specify the problem you’re solving. That way you can derive key success metrics based on the time your data product is called, used, or re-used. Then, you can calculate the total value delivered to the organization. Based on: The number of distinct use cases and customers served. The number of calls and/or times your Data Product is used or invoked. (Each call or usage must equate to a specific value.) The number of distinct users served.

These rules may seem simple, but they’re incredibly powerful tools for successful Data Product Management. Remember, A clear definition of value combined with a skilled, focused team is always an equation for success.