Data Product Strategy should flow from the same source as your product or business strategies - your customers. Your customers are your purpose - the reason for your business’s existence. Creating value for them dictates your ultimate success or failure.
There is only one valid defition of businesses purpose: to create a customer - Peter Drucker
This can be a complicated question depending on your business. If you are in a business with many customers - a better question might be who is your ideal customer (the customer you can create the most value for). If you only have a few customers it should be pretty obvious. In product data management - your customer may be internal or external. Internal customers could be a Board of Directors, Management Team, or Engineering Team. External customers could be end-users in a software application or current or prospective clients.
This question is at the core of the Jobs to Be Done Theory [JTBD] - the heart of which is discovering the why behind customers’ choices as they seek to make progress in their lives. As it relates to data product management - the JTDB could be: re-assure your inventors that their money is in good hands or prove to your client you are saving them money every month. While sometimes obvious - it is not always abundantly clear why your customer hired you. You may think it is because you have an amazing product, but it could actually be because you have a really good charismatic salesperson. Or maybe a newspaper suddenly starts selling more papers - you as the newspaper owner assume it is because of the string of great stories you have been writing recently. The actual JTBD could be that using your newspaper as a fire starter in the winter is the most economical option.
The key to getting hired is to understand the narrative of the customer’s life in such rich detail that you are able to design a solution that far exceeds anything the customer themselves could have found words to request. In hindsight, breakthrough insights might seem obvious, but they rarely are. In fact, they’re fundamentally contrarian: you see something that others have missed. - Clayton M. Christensen, Competing Against Luck
The key here is to spend a lot of time listening to your customers so you can get to the root of the true reason they hired you (and continue to hire you).
Now that you have an idea of your Purpose its time to put that into practice.
Objectives and Key Results [OKRs] are a framework for focusing efforts to get results for your customer’s jobs to be done. The OKR framework was introduced by Andy Grove at Intel in the 1970s [taking many concepts from Peter Drucker’s MBO framework]. It was further popularized by John Doerr and Google in more recent years.
OKR Formula - I will [goal/objective] as measured by [key results/metric]
Example: Objective - I will run a 5k in under 20 minutes by July 1st as measured by
(KR 1) Running 3x per week for atleast 20 minutes
(KR 2) Increasing my speed per mile by 30 secounds each week
(KR 3) Increasing my distance by 0.25 miles per week
Example: Objective - I will enter my next board meeting prepared and confident my data is accurate.
(KR 1) requests for data will go our 2 weeks in advance of the meeting
(KR 2) data reconciliation process will be complete 5 days before the next meeting
(KR 3) data feedback loop will be shortened by 50% by having a synchronous /live meeting to discuss modifications.
When setting objectives it is most helpful to have cascading objectives - that is company OKRs that connect to team OKRs that connect to individual OKRs. This keeps everyone in alignment and can bring to light competing priorities and interests quickly. Additionally, the best team and company objectives come out of a collaborative development process (everyone should be involved in the development of the objectives that impact them). People show higher ownership when they are part of the development process of an OKR. [See The Psychological Ownership Principal].
“Measurement against a standard makes you think through WHY the results were what they were.” - Andy Grove
A goal-setting framework is crucial for product data success. Without objectives, it is far too easy to chase rabbits and spend tons of time building things that are not needed or overbuild things that are only needed once. Objectives bring focus and what gets focus gets better.
Your objectives can be extremely hard to execute if you don’t have the right people in the right organizational structure. Below I will discuss a few different organizational structures so you can identify which structure best resembles your situation and the benefits and understand pitfalls of that particular structure.
Most companies start with this data model. In this model, requests go to a data or business analyst. This analyst usually services all types of data requests and reports to IT/Engineering. As a company grows this job can become very challenging as multiple business units compete for scarce resources - and lack of specific business or domain knowledge hampers true value creation. This model can easily lead to frustrated analysts who are always caught in the middle - feeling always behind and unable to make everyone happy.
Larger companies that can afford it - can start embedding data analysts in each functional group. In this model, requests go to a data or business analyst in the functional team. They are then supported by a centralized team for data pipeline creation, data model creation, etc.
Mid-size companies may find that training existing employees that already have domain knowledge can be the most cost-effective way to scale their analytics efforts and empower their people. In this model, requests go to a dual-role employee in a functional team. They are then supported by a centralized team for data pipeline creation, data model creation, etc. While this model can be very effective it can be hampered by dual-role employees who aren’t dedicating enough time to one or both of their roles.
Each of the above organizational structures has its trade-offs. Two of the major trade-offs are centralization and domain knowledge.
The biggest advantage of centralization is efficiency. A centralized team - especially if it reports to IT/Engineering should be equipped with the right tools, system access, and hopefully discipline to create good reusable work. The results of this team may be slower at first but they won’t typically produce manual processes or poorly designed data structures - which means faster in the long run.
The biggest advantage of the decentralized team is effectiveness. Since a decentralized analyst is often solving their problems or their own team’s problems there is less probability of misalignment of business objectives. Although potentially more effective, efficiency can suffer if these analysts are not equipped. They can end up doing a lot of repetitive work and spend a lot of time reconciling data.
Short answer - there isn’t one. Each has its own trade-offs. However, I do think there is a best mindset. Focus on effectiveness first then efficiency. Having this mindset, I do tend to prefer de-centralized approaches over centralized approaches. I think it’s better to be strong in domain knowledge and a little bit inefficient. Even with this approach, you have to be careful to not let the inefficiency consume so much time that it becomes ineffective.
If you are on a centralized data team I think it is very important to go outside of your job description and increase your domain knowledge. Another thing you can do is partner with a domain expert and do rapid prototypes. Excel/Sheets or Airtable are great tools for this and can greatly increase your efficiency. The more you can train your business counterpart on prototyping and yourself in domain knowledge the better you can work together.
While every organization needs some kind of structure - there is flexibility to create more informal groupings of people to help either encourage discipline for a de-centralized team or gain more domain knowledge for a centralized team. Regardless of the structure you pick take advantage of other ways of gatherings to compensate for the weaknesses in your structure.
Now it’s time to put your objectives on a road map. However, it’s important to set your expectations for your road map first.
As illustrated above it’s important to hold your roadmap plans loosely and be willing to change your plans as your business environment changes. Agile thinking is crucial to this process. A Goal-oriented roadmap rather than a traditional output-focused roadmap will allow for flexibility in tactics as a team is seeking to complete its objectives. From my perspective, a roadmap can be as simple as your high-level objectives with committed delivery dates. Another component to your road map should be some aspirational objectives - objectives that you want to give a shot, but can’t put a deadline on it because there are too many unknowns. These are important so you can keep innovating and not grow stagnant.
Lastly - you need a feedback system. You need to know if what you are doing is working, if you are making progress, etc. Data collection, storage and distribution is a huge part of this feedback loop. to learn more - read What is a Data Stack?