By James Humble, Senior Consultant at Nimble Approach
As a Product Consultant, understanding data is key to helping product teams make informed decisions and deliver meaningful business outcomes. But with so much data available, knowing where it comes from, what it tells us, and how to turn it into actionable insights can be a challenge.
In this blog, I’ll share my approach to understanding data as a Product Consultant: how I assess the data available, document my findings, and use them to help connect technical teams with business stakeholders and support better decision-making.
This isn’t a one-off exercise. As a product evolves, so does the data behind it. Building and maintaining a living document helps you revisit your findings, challenge assumptions, and develop a deeper understanding of the product over time.
Understanding Data: The What, Where, When & Why
When I sit down to analyse data on a product, I break my workflow down into four simple questions: What, Where, When, and Why.
1. What data?
The first step in my data analysis journey is to start cataloguing all data attributes within the product. This means cataloguing every form input, database field, and API response payload that powers the product.
Now, although this is a simple task on paper, it can be quite time-consuming depending on the product you’re working on.
My Top Tip: If the scope feels huge, instead try to focus specifically on the attributes required for upcoming features on your immediate product roadmap. This keeps your efforts tightly aligned with upcoming sprint goals while delivering immediate value for the product team.
2. Where does the data come from?
Once I have a view of the data we’re using, the next crucial question I ask is: Where is it coming from, and what is the ‘source’ of the data?
This is your first step into a more technical approach. You stop just accepting that a field is present on a screen and start querying it at a deeper level. As part of this step, I also look to identify how that data actually enters the product.
This interrogation is hugely important because it allows you to test whether you can truly trust your data. In my experience, digging into sources often unearths some surprising truths:
- You might find attributes coming from legacy systems nobody realised were still connected.
- You might find data being duplicated across multiple systems, creating competing “sources of truth” – or worse, conflicting data that confuses users.
My Top Tip: Working through this step carefully alongside a Data Specialist within your organisation will help you get the absolute most out of the process.
3. When is it captured?
The next valuable thing I consider is when is the data being captured. Is it a one-time data pull that never updates again? Or is it an Application Programming Interface (API) configured to refresh daily or weekly?
Understanding this cadence is vital. It prevents you from accidentally designing a business process or user experience around stale information, or data that is never updated at all.
Consider a scenario where a UI design displays live stock balances, but the inventory database only syncs via a daily batch job at 00:00 GMT. The user experience quickly breaks down. Understanding the refresh cadence of this attribute helps you avoid designing business processes around stale or static information.
4. Why is it needed?
In the final step of the analysis, I start to challenge everything I’ve documented. I ask:
“What is this actually driving? Why do we need this data?”
This helps you really question the true value of a piece of data. What business outcome is it driving, why is it needed, or – quite possibly – is it even still needed at all? You’d be surprised how many fields exist purely because “they’ve always been there.”
Example: Structuring Your Initial Findings
To bring this approach to life, here is an example of how you might construct a table mapping data for a fictional investment organisation. This is an overly simplified view, but it provides a clear starting point for how you can structure your findings:
| What (Attribute) | Where (Source) | When (Customer Journey) | Why (Comment / Value) |
| Customer name | Customer Database (CDB1) | New customers | Identify the customer who holds the investment account |
| Customer Address | Customer Database (CDB1) | New customers | Physical communication & mandatory identity verification |
| Investment Amount | Product Database (PDB2) | New investment | Tracks initial deposit amount for the active account |
| Rate of interest | Product Database (PDB2) | API – Bank of England (BoE) | Live interest calculation; updated daily via API |
| Email address | Product Database (PDB2) | New customers | Account notifications and digital correspondence |
| Marketing consent | Marketing Database (MDB3) | New customers | Ensures compliance with contact preferences |
Pulling it All Together: The Data Dictionary
In my workflow, I’ll start pulling all of my findings together into a single, practical business artefact: a Data Dictionary (DD).
Now, a DD can contain as many or as few column headings as you like. Remember, it’s your analysis, your findings, and your mapping – so there isn’t a strict “right or wrong” way to set it up. Do what works best for your team.
Key Columns for a High-Impact Data Dictionary
Taking the findings from our earlier steps, a typical DD draft I’d pull together might look like this:
- Attribute Name: The technical identifier (e.g., investor_account_status).
- Display Label: The user-facing UI label (e.g., “Account Status”).
- Data Format: String, Integer, Decimal, Boolean, Date.
- Source System & Table: The origin database or API endpoint (e.g., PDB2.account_tbl).
- Refresh Frequency: Real-time, Hourly, Daily Batch, Static.
- Business Logic / Rules: Validation rules or transformation logic (e.g., Must be > 18 years old).
Best Practice: Keep your main DD inside a single, filterable workbook tab. The reason for this is simple: it allows for easy interrogation, filtering, and comparison of the data. If you decide to break this out across multiple tabs or documents, doing that analysis becomes unnecessarily complex.
What to Look Out For: Real-World Data Pitfalls
Understanding which processes use what data makes this a genuinely powerful artefact in your toolkit. Looking at your data through this lens paints a clear picture of which attributes are most important due to their high usage across multiple journeys.
Furthermore, if your analysis shows that a certain heavily relied-upon attribute rarely receives updates, that immediately flags a potential future change to raise to your product team.
To illustrate how this functions in practice, here is a practical scenario showing how a discovery within your Data Dictionary translates into tangible business decisions:
1. Validating the Finding
While cataloguing attributes for an investment interface, you review a field named current_interest_rate. The delivery squad assumes this field updates instantly as a user adjusts their deposit choices.
However, when querying the source alongside a Data Specialist, you discover that it is pulled from an external service via a midnight batch run at 00:00 GMT. The attribute isn’t dynamic; it remains static throughout the day.
2. Explaining the Business Impact
Instead of framing this solely as a technical nuance, a Product Consultant highlights the commercial and user risks:
- Customer Impact: Lower CSAT: When market rates shift mid-day, users encounter outdated return calculations, triggering confusion and possible increase in customer support queries.
- Business Impact – Compliance & Regulation: Presenting inaccurate yield projections in financial applications introduces serious regulatory compliance risks.
- Product Team Impact – Wasted Development Effort: Building frontend components under the assumption of real-time feeds leads to failed testing and costly rework during delivery.
3. Agreeing Next Steps with your Team
With the issue transparently mapped, you’re able to collaborate with the Product Owner and Tech Lead to evaluate the Data Dictionary and establish an actionable path forward which could be one of the following design outcomes:
- Immediate UX Adjustment: Introduce clear messaging stating “Rates updated daily at midnight” to manage user expectations and maintain regulatory standards. This could act as a permanent solution or a quick win whilst the team is looking at other options.
- Roadmap Prioritisation: Raise a spike for the Development team to evaluate the feasibility of triggering on-demand API calls whenever users are in the deposit journey.
My Top Tip: Spotting these data nuances early in discovery prevents flawed features from reaching production, protects development capacity, and builds stakeholder confidence in your product strategy.
Validating Findings with Stakeholders
Once I’ve finished drafting my DD, I’ll take the opportunity to walk the wider product team and stakeholders through the document to demonstrate the findings.
Don’t skip this step! Running a short walkthrough session usually provides hugely insightful context and helps fill in some of those inevitable blanks you encounter during solo analysis.
Translating Data into Real Business Insight
Now that most of the hard work is done, you have an artefact that serves as a living, breathing document for your product team. It’s now time to translate these technical findings into real business insights.
Bringing value into the conversation is a great angle for Consultants. Business leaders and Product Owners are always looking to enhance their product or business offerings. By being able to show them clearly what value a piece of data brings – or where missing/infrequent data is holding a feature back – you give them the confidence to make informed product decisions.
Putting This Into Action: A Simple 4-Step Checklist
To apply this methodology on your project right away, there is no need to map out your entire enterprise ecosystem immediately. Instead, start small by applying this structured process to an upcoming piece of delivery work:
- Select a single capability: Rather than tackling everything at once, isolate a specific user journey or a User Story from your immediate delivery plan.
- Apply the core questions: Document each data field within that interaction by answering: What is it, where is the origin, when is it refreshed, and why is it needed?
- Build a practical Data Dictionary: Capture your observations inside a unified workbook tab detailing technical identifiers, systems, refresh cadences, and business logic.
- Run a brief walkthrough session: Schedule time with a Tech Lead, Data Specialist, and Product Owner to review the findings. This ensures shared alignment and surfaces technical edge cases prior to build.
In Summary
I hope sharing my approach has provided some useful insight into how you can approach data on your own projects.
By taking the time to build a technical data inventory and a Data Dictionary, you deliver two major outcomes:
- For Senior Stakeholders: Transparency that builds trust, ensures compliance, and provides confidence in data-driven decision-making.s, we’d love to talk. Get in touch with the team at Nimble Approach to continue the conversation.
- For Delivery Teams: Clear technical clarity on data sources, schemas, and update rules, reducing ambiguity during sprint development.
