Better Practices
Published in

Better Practices

How Postman Does Data Democratization

A story from the Postman Data team about decentralization, breaking down silos, and sublinear scaling

  • Sheer volume of data
  • Diversity of business rules
  • Interpretation across various business/product domains
  • Making collaborative decisions across business/product domains

An initial thought-exercise

  1. Decision-making within the organization is moving from a few leaders to all knowledge workers
    — One way to look at it is rather than falling on CXOs for making decisions (which might be good at an early stage but not scalable), more and more people in the organization are making decisions
    — There is a 10% rate of increase in decision-makers month-over-month
  2. Increasing popularity of your organization/product/platform is resulting in more and more users onboarding i.e., data size is increasing at 10% rate month-over-month (a decent rate)

A brief history of Postman’s data team

A centralized data team independent model
A decentralized model where everyone has access to data and can drive decisions independently

Our goal is data affinity and maturity

  • Data team lens: What are the fundamental hierarchical needs of data?
  • Consumer lens: What is the lifecycle of problem-solving with data?

The hierarchy of needs of data

Source: “The AI Hierarchy of Needs” by Monica Rogati

The lifecycle of problem-solving with data

The Lean Analytics Cycle

Postman data team’s mission

We enable (rather than service) the Postman organization to confidently make data-driven decisions with an analytical and iterative mindset.

The fundamentals of data democratization

  • Leadership buy-in to advocate the idea
  • Inspiration for everyone to leverage data in their day-to-day decision making
  • Guidelines of what it means and what it does NOT mean (i.e., codifying the platform)
  • For data team members: Ability to measure that we are driving the right behaviors and make sure that we are improving over time


  1. We encourage decision-makers working with data to ask the right questions:
    — What kind of hypothesis would you like to validate with data? (e.g. Are users adopting a feature X over time?)
    — What kind of decision are you planning to take using this data?
    — Which objective and key results (OKRs) would this decision map to?
  2. We help showcase the value of data-driven decision making to inspire everyone around us
  • Raising a data acquisition request from data sources
  • Raising a bug related to data on the data team

Creating the Postman data-democratization platform

  1. Data integration as a platform
    — An integration to acquire data should be as seamless as possible (with the proper review gates including security checks)
    — The outcome of an integration (i.e., raw data should be accessible to everyone in the organization)
  2. Data transformation as a platform
    — Anyone can transform the data to cater to their needs based on the guidelines
  3. Data visualization as a platform with the following capabilities:
    Measure to ensure we are on the right track
    Forecast to ensure we will reach our goal
    Experiment to play around with the measured data to reach the intended goal
  4. Data knowledge repository
    — To learn from each other’s successes and mistakes

Why we chose Kimball modeling

Ownership framework

How do you define ownership of a dataset?

  1. A domain in which products are built to cater to end users
  2. Entities in a domain which creates an accountability definition such as Postman Collection is in X domain
    — Going one level further, APIs are defined and maintained by the corresponding team

Why we made certain technological choices

  1. ELT (extract, load, and transform) rather than ETL (extract, transform, and load) for data integrations
    — This helped us ensure that the transformations are taken up once the raw data is available, hence the context of business logic around transformations is not lost during the integration
    — Since raw data is available for everyone, they can build their own transformations if and when required
  2. DBT (Data Build Tool) as a transformation engine
    — From a platform standpoint, we encouraged everyone to contribute to business logic transformations on a centralized DBT, hence encouraging an org-wide contribution
  3. Looker as a data modeling and visualization platform
    — Looker provided us a way to disseminate knowledge with various teams in the organization
    — One key advantage of Looker is an abstraction layer (i.e., models) on top of warehouse tables that help us maintain consistent communication throughout the organization

How we measure

A final thought-exercise

  • Understand the lifecycle of data to archive/expire data when it is not required anymore
  • Write modules/utilities to measure the quality of code by contributors to the platform so that we support efficient code writing (i.e., optimized SQL queries)
  • And so much more; stay tuned as we continue sharing our learnings




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Shubham Bhargav

Dabbler in product, data and organization design. #learning-together