Dr. Mario's 2nd 🧠

Hello Product Data Team Goodbye Ad Hoc Work

6 min read

rw-book-cover

Metadata

Highlights

A service model can work well in situations with clearly-defined problems and a need for quick turnaround, especially for some stakeholders (View Highlight)

Being a product-oriented data team, thus, is not primarily about just “putting your focus on different things”; It is about shifting from many disconnected low-value work items towards fewer high-value projects combined into a single long-term vision. (View Highlight)

this shift is hard and takes time (View Highlight)

The data team was already behind as we received requests to analyze products we had never heard of and to ingest data we didn’t know the source of. Data teams need to understand the data they get, the context in which it is produced and meant to be used, and the language of the internal customers they deliver it to. If data and internal customer language are new and hard to understand, it becomes a significant hurdle to delivery. (View Highlight)

I’m currently on 1, wanting to switch to 2

The previous data PM considered two different modes for operating in this environment:

  1. Go all-in on the service model but adapt the services model to the fast-changing environment. Train specific domain experts for each major domain and have them stay up to date all the time. That would be one data engineer and analyst for sales, one pair for product management, and one pair for marketing.
  2. Go all-in on a product model, stop implementing ad-hoc requests, and start to implement a continuous discovery and delivery process. At the time, it wasn’t clear what this meant, but it was clear what it did not mean: it did not mean doing disconnected work driven by ad-hoc requests that don’t fit together into a larger picture (View Highlight)

was also clear that we would only make significant steps in the right direction if we stopped implementing small requests that individual end users submitted (View Highlight)

I needed to align our team’s priorities with the new company direction, which meant serving some parts of the organization more than others. (View Highlight)

that doesn’t mean that management or your department head will approve of such a change of process inside the data team, let alone stakeholders that are used to submitting tickets and getting them implemented within a week. Delivering visible progress is the easiest way to convince management and stakeholders that this change is the right direction for the company. (View Highlight)

Depending on your previous situation, you might:

  1. Implement a regular planning event with all your stakeholders, such as quarterly planning
  2. Implement a backlog to show off priorities
  3. Implement a roadmap to communicate strategic focus
  4. Implement regular but infrequent meetings with key stakeholders to discuss major initiatives
  5. Communicate your planned new way of working internally. For example, through a blog post
  6. Propose new work items you come up with yourself that align with the company’s direction (View Highlight)

we had already implemented quarterly planning events, but those events didn’t feel like an improvement to the ad-hoc way of working. During this meeting, all stakeholders would request their list of reports & dashboards for the quarter, and we would prioritize them together. We went from having ad-hoc requests daily to getting them in one big batch at the beginning of the quarter. That didn’t feel like a huge improvement yet. (View Highlight)

Everyone did see that a change was necessary, so everyone was up for a try. Here’s how it went down: • I first thought through a list of things the team and I thought were attractive to the company. • I asked all stakeholders to provide their “list” before the planning meeting. • I aligned both lists and packaged them into large blocks, eliminating everything that seemed optional to the company. • I had one event with the stakeholders to decide which 1 or 2 of them we’d do. (View Highlight)

The discovery and potential planning happened in infrequent but regular deep meetings with the key decision-makers. This discovery process directly involved other product managers, top management, the Head of Sales, the Head of Marketing, team leads, and other critical decision-makers (View Highlight)

Communication with critical decision-makers was surprisingly easy to nail. It meant doing what every other PM does: focus your discussions on problems and alternatives, not your shiny solutions. Ask questions, understand pain points, and understand what these decision-makers want to achieve themselves. (View Highlight)

Slowly, we learned the key ingredients to great product-oriented data work at our company:

  1. a clear vision,
  2. big chunks of work that have a visible and understandable value to the company,
  3. Embracing the duality of internal customers and communicating with both groups (a lot!),
  4. a focus on the high-level decision-makers when it comes to understanding customers. (View Highlight)

New highlights added 2023-10-11

reason. A service model can work well in situations with clearly-defined problems and a need for quick turnaround, especially for some stakeholders. And if it’s working well, you will (View Highlight)

Being a product-oriented data team, thus, is not primarily about just “putting your focus on different things”; It is about shifting from many disconnected low-value work items towards fewer high-value projects combined into a single long-term vision. (View Highlight)

The places I’ve been to didn’t have a PM

The business intelligence team I PMed managed systems that served around 100 unique users each week. (View Highlight)

New highlights added 2023-10-28

data teams often adopt a service-oriented approach for a reason. A service model can work well in situations with clearly-defined problems and a need for quick turnaround, especially for some stakeholders. And if it’s working well, you will face resistance to changing the team’s direction. So, it is essential to understand when this transformation makes sense and when it does not. (View Highlight)

Delivering visible progress is the easiest way to convince management and stakeholders that this change is the right direction for the company. There are a bunch of things you can try to show visible progress. All of them should have two characteristics:

  1. They should be small. You won’t get large changes approved. You only get fast results with quick and, therefore, usually small changes.
  2. They should still be meaningful so that you can show actual progress. (View Highlight)

Implement a backlog to show off priorities (View Highlight)

Webmentions

Loading webmentions...

Graph View