A data plan that names the first three things to build, and who owns them.
Strategy decks that list every source and every use case rarely get funded. We start with the decisions your leaders are making with poor data, trace each one to its sources, and build a plan around the few data products that fix them.
A data strategy sets out what data a business needs, how it will be collected, governed and used, and who is responsible for it.
Cohash builds data strategies that start from specific decisions, assess your current sources and platform, recommend a target architecture on Snowflake, Databricks or Microsoft Fabric, and define an operating model with named owners and a funded first phase.
you probably need this if
Your last data strategy listed forty use cases and none of them got funded.
Leaders make pricing or staffing calls on numbers they don't trust.
Two business units bought different data platforms and both are half used.
We pieced these together from Data Strategy situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
A data lake that the business still works around
composite · not a client story
Beforethe situation
A lake on cloud storage holds copies of most operational systems. Business units still report from extracts and spreadsheets because nothing in the lake is documented, modeled or owned, and the platform team is being asked to justify its budget.
What we dothe work
We interview leaders about the decisions they make each month and the numbers they distrust. The most valuable decisions are traced to sources already in the lake. Two or three data products get named business owners and a definition of done, and we list what the platform team can stop doing.
Afterwhere you end up
The platform now has a short list of products with owners, and a reason to exist. Budget conversations are about particular decisions rather than terabytes stored.
case file 02
A new CDO, an AI mandate from the board, and no data owners
composite · not a client story
Beforethe situation
The board wants AI use cases in next year's budget. Then the new CDO looks closer. Customer, product and employee data each have several unofficial owners, nothing is classified, and whoever runs a system decides who gets in.
What we dothe work
We map the AI ideas already on the table to the data each needs, and rate each source for quality, classification and access. Ownership goes per domain to a business owner and a technical steward. The roadmap sequences only the governance work the first AI use case needs, and parks the rest.
Afterwhere you end up
The CDO has an operating model with named owners and a first use case on governed data. The next AI project starts from classified, owned sources. Nobody has to renegotiate access from scratch.
How a data strategy traces decisions back to sources and owners
We begin with the decisions leaders make and trace each to the data products and sources behind it. Add a platform choice and an operating model with named owners, and you have a funded first phase.
How a data strategy traces decisions back to sources and ownersWe begin with the decisions leaders make and trace each to the data products and sources behind it. Add a platform choice and an operating model with named owners, and you have a funded first phase.01 · DECISIONS02 · DATA PRODUCTS03 · PLATFORM04 · SOURCESranked by valuescoped intoaccountable forbuilt ongovernstraced toBusiness decisionspricing · staffing ·retentionRanked use casesvalue · data difficultyFirst data productscustomer · revenue ·memberOwners and stewardsone per domainTarget platformSnowflake ·Databricks · FabricAccess approachIdP groups · accessreviewsSource systemsCRM · ERP · claims · SaaS
01 · Decisions
Business decisionspricing · staffing · retention → Ranked use cases · ranked by value
Ranked use casesvalue · data difficulty → First data products · scoped into
02 · Data products
First data productscustomer · revenue · member → Target platform · built on
Owners and stewardsone per domain → First data products · accountable for
03 · Platform
Target platformSnowflake · Databricks · Fabric → Source systems · traced to
Business decisions → Ranked use cases: ranked by value
Ranked use cases → First data products: scoped into
Owners and stewards → First data products: accountable for
First data products → Target platform: built on
Access approach → Target platform: governs
Target platform → Source systems: traced to
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Interviews
Conversations with business leaders, analysts, data engineers and security to find where data slows decisions down.
step 02
Assessment
A review of sources, platforms, pipelines and reports, measured rather than described.
step 03
Options
We price out each architecture and operating-model option, risks included, and talk it through with leadership before anyone picks.
step 04
Roadmap
A phased plan with owners, budget ranges and measures for each phase.
you keep
What you're left with
We write these for your Data Strategy setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Ranked list of decisions and use cases
yours to keep
report02
Current-state assessment of data sources and platforms
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Data strategy lead
Data architect
Data governance lead
Analytics product owner
Enterprise architect
due diligence · data strategy
Questions to ask any partner, including us.
Put these to anyone bidding on your Data Strategy work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which decisions will this strategy improve, and how will we know it worked?
A strategy organized around platforms and sources tends to stall at funding. One tied to named decisions gives the business a reason to pay for it.
Q2
What will you recommend we stop doing?
Roadmaps that only add work rarely get delivered. A credible plan names reports, pipelines or tools to retire, which frees people and budget for the new work.
Q3
Who will own each data product after you leave, by name or role?
Ownership without a named person defaults to the platform team, which can't answer business questions about the data.
Q4
Will your platform recommendation take account of the contracts we've signed and the skills our team has?
Switching platforms has costs that don't show up in a feature comparison. Committed spend, retraining and migration risk are among them.
Q5
Is the first phase small enough to fund and finish this year?
Phase one should be specific enough to estimate and deliver. If it reads like a capability list, the strategy will likely sit on a shelf.
01How long does a data strategy engagement take?
That depends on how many business units and source systems are in scope. A strategy for one domain is much shorter than one for the whole enterprise. We agree the scope and how long it'll take before we start.
02Will you recommend a platform you resell?
We don't make our recommendation depend on resale. We compare the platforms against your workloads, team and contracts, and explain the trade-offs.
03Do you include AI in the strategy?
Where it fits, yes. Most AI use cases need the same governed data that reporting uses. We plan them together instead of as separate projects.
04Can you build what the strategy recommends?
Yes. Our data engineers, modelers and governance specialists can deliver the first phase, or support your team while it does.
05Do you interview business leaders, or only IT?
Both, and business leaders first. The decisions they make and the data they don't trust set the priorities. IT and data teams then tell us what it would take to fix each one, which keeps the plan grounded in what the systems can actually do.
related
Often paired with
Projects on Data Strategy usually end up touching one of these, so they're worth a look.