In a nutshell, Data Product Management teams are responsible for analyzing and implementing data product opportunities within an organization. When it comes to successful data product management, many of the same basic principles apply as with any other technical product management initiative. But there are some unique differences that must be understood 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 identify more impactful best practices, or “rules” that Data Product Managers and their teams should embrace when building data products.
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:
- 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. Data science is filled with extremely analytical people. Sometimes, over analysis can lead to an incredibly cool project that really isn’t going to deliver much value. Understanding the actual value of the product, by stating who will benefit and exactly what those benefits are, will keep the data product delivery team focused and motivated throughout the entire product development lifecycle. It will also help highlight and reinforce the specific value of the product every time you deliver a feature (or set of features) to the customer. And remember be specific. 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.
- 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” the priority will be to arrive at the simplest, most effective working solution as quickly as possible. While 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 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.
- Keep all your work visible. It’s important to monitor your team so that nothing is being worked on that the Data Product Manager or Product Owner hasn’t included in the current Sprint or delivery cycle. That includes functionality that’s not explicitly required to satisfy the Acceptance Criteria. One exception to this rule is allowing time for the team to challenge the Acceptance Criteria if it’s vague or unclear, or if it might not be enough to solve the customer’s problem. As you’re considering whether one or both of 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.”
- Be the expert where it matters. You don’t have to master every feature or aspect of your product but you better understand these points thoroughly: The customer AND their needs. The technology at hand, particularly when it comes to 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.
- Assemble the right team. While no one disputes the value of having “data gurus” around, at the end of the day we’re still building software products. Strong data and software engineers are vital to success. They become invaluable when they possess deep domain knowledge as well. Next, make sure someone on the team can implement and manage automated test practices so that 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 as the Data Product Manager you’ll fulfill this role, but don’t underestimate the value of having a second opinion here. On that note, you can 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. In other words, don’t give anyone (including you) more than can be handled in the time given.
- Calculate the specific value of the Data Product. Since these products are usually part of a larger solution, you need to make sure you’re inherited all the customer requirements other related products serve, in addition to the specific 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. You can then 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 Data Product Management success. Remember……
A clear definition of value combined with a skilled, focused team is always an equation for success.