Building Data Platforms: The Mistake Organisations Make | Issue #54
Building Data Platforms: The Mistake Organisations Make | Issue #54
Thinking of Building Your Own Data Developer Platform? Here's a note from platform developers.
As data platform developers would relate, it’s undeniable how thrilled and hopped up we get on the meditative process of building things. Sometimes, the hit is so remarkable that developers might even start building just for the process, not really getting bothered by who or when somebody uses what we built. I bet product managers would relate.
While this may pose as a simple mistake to avoid, it’s often a looming edge case, and it’s easy to fall off. Just like how some eccentric architects would eat up space for aesthetic and funkily symmetric shapes in budgeted projects.
But the sad reality is, in business, everything is budgeted.
This doesn’t mean there is no space for innovation. Instead, it means that innovation flowers under the direction of the business. And for that, you need to listen to what the business’s mouthpiece is saying: The User is God.
Man proposes, God disposes.
Platform developers can make plans, but Users determine how things with turn out.
Where Platform Development Fails
Let’s keep aside the huge resource-sucker that platform development could become. However, there are some organisations that genuinely wish to own the entire stack organically and have the bandwidth and budget to spend two or more years on data platform development.
In doing so, there are a lot of things that can go wrong at the final hour. At the end of two years, the organisation may come face-to-face with its own prioritisation fallacy: They never planned a concrete adoption trail for users (their own employees) to discover and follow. It becomes more of a push-down at that point (because, after all, employees are bound to follow top-down enforcement, unlike customers).
What a dead end in data platform culture looks like: Consistent tracks stacking up to enhance the product and no streamlined effort or prioritisation for a parallel adoption track. A platform can be super-optimised and feature-rich but ultimately fail if it doesn’t get adopted—as good as an inert product.
It’s, therefore, a non-negotiable to pair maturity & adoption tracks once the MVP is up.
How do Best-in-Class Data Platforms Strategise Adoption?
Lighting up the experience path 🔦
Approach/Workflow Templates. This is a biggie!
For example, Kanban and Agile templates in JIRA, design templates in Canva, Data Product templates in DataOS, Workspace Automation templates in Databricks. Any new ecosystem demands templatised entry points to enable users to follow a journey they are not otherwise familiar with.
Experience/Journey-based documentation.
Instead of learning-based documentation. The user doesn’t care about learning a new ecosystem unless they have comfortably penetrated into the ecosystem and see one layer of value - ease of use/potential in reduction of existing efforts.
A way to get a flavour of What’s In It For Me (WIIFT), aka, the User
Knowledge of value is especially important for me as a user for whom the cost of entering the platform ecosystem could be significant in terms of my learning curve - my mind naturally resists new habits. I want to know what I’m getting into first. This could be done in several ways, such as:
Trial experience (demo environments, simulations, base credits, etc.).
Case accounts that are relatable to user personas- not just industries at large.
Genuine usage accounts from your users that new users can relate to.
Penetrating into existing habits 💉
Extensibility to frequently used native tools is critical, which are part of the target’s fundamental work experience (e.g., git for devs, BI tools for analysts). This doesn’t mean a mashed-potato-like packaging, which most adolescent platform vendors are known to do as a quick hack.
The platform that ends up getting adopted isn’t mashed potato but a common interface to operate data entities declaratively or via self-service for all involved data citizens the platform serves.
A data developer platform becomes the facilitator of existing stacks, tools, and consumer-facing applications to essentially make operations, maintenance, and data both proactive and reactive.
Will not bore you with the capabilities of data platforms, but if you’re curious, here are a few pieces which highlight them:
Visibility and The Art of Possible 🖌️
Product Roadmap
Building a data platform also means building an ecosystem where your users can live as long as they decide to be in the data industry. Take GitHub for example; it’s essentially the second home for deployment teams. Therefore, when creating this ecosystem, you create with your users.
Beyond usage metrics, it’s also the roadmap that users need to be looped into. The users who are champions of the platform experience would not just influence the roadmap through passive usage but also active requests and suggestions. In a way, the roadmap is also a view into the art of possible- excite users with what they can do.
Embedded FAQ in all Platform Segments
When looking at any product, one of the easiest ways to find out the most important features is the FAQ - a collection of queries and answers to frequent doubts from users and probable points of confusion predicted by the developers.
This visibility saves users from high-friction zones, such as carving out time for calls, pondering on questions and dropping out because of minor confusion (which has a tendency to create high friction to invest any further time in understanding more), and general frustration with the experience.
Specific Embedded Guides
Yes, templates are one medium for guidance. But is it enough? Guidance through the product journey is a highly undervalued component which makes or breaks the user experience. Even a relatively trashy product with a good step-by-step guide is more well-accepted and adopted by users.
Users, with exceptions, have a tendency to get lost in new spaces if the environment isn’t familiar. Guidance, thankfully, comes in many forms. Be it the step-by-step structure of documentation, embedded tours (do this and then do that), automated recommendations, or specific guides on how to establish specific goals with the data platform.
Final Note
If you’re planning on building a data platform, it could be easy to forget that alongside build tracks, the adoption game also needs to be strong. Both production and adoption go hand in hand to make a platform truly valuable and deeply embedded in the lives of its users.
And in case you missed, as a developer of a platform that shoots out data products on demand, for us the product mindset does not just apply to how the data is getting managed in the platform ecosystem. It also largely applies to how the platform is being built from the ground up - with the user’s adoption pains in mind alongside their ambitions.
 | A guest post by
|
at dlthub we regularly see users come and replace their homebaked "undocumented framework built by one guy" with standards the entire team can use.
I guess part of the lesson is to treat your data products, well, as data products, and consider the user and the "PMF"