Highlights §
- We went from implementing long lists of dashboards and reports for sales, customer services, and management to turning analytics inside the company upside down. When I left, we had just finished implementing a multi-year vision for the future of the company’s data platform. (View Highlight)
- We went from ad-hoc work for internal users of the business intelligence systems to proactively designing and building a few data products to help product, sales management, and the executive team make critical decisions better and faster through data.Going from a service team to a product team was necessary for us because our previous way of working wasn’t practical anymore. (View Highlight)
- In some situations, service teams are necessary and quite effective; 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)
- The process outlined in the articles sounds easy: “focus on users and be proactive,” but most data teams already do focus on users, especially when they are service-oriented. And they are proactive. They do come up with great ideas for new dashboards, and they proactively set up workshops and the like. 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)
- On the business intelligence side, the data team at Unite focused mainly on delivering dashboards and reports, building data pipelines, and maintaining the business intelligence system. The work came in through tickets created by internal customers in sales, customer service, marketing, and other departments. (View Highlight)
- As an internal customer-focused team, we frequently talked to these end users to understand the requirements of a specific report or to gather more ideas for other reports. The team had no problem delivering on asks and built up significant technical and business knowledge. Thanks to that, the reports & dashboards were built quickly, and our stakeholders were happy. (View Highlight)
- The situation was great for a service-oriented team. Just like when you call your Apple customer service, the problems we received needed quick implementation. Our report turnover time was similar to a basic repair; finishing one new report took a few days. (View Highlight)
- Both the iPhone repair service and our service orientation succeed because of three factors:
- The problem is apparent, clear, and well-defined.
- There is a step-by-step solution to the problem.
- The tasks need quick implementation. (View Highlight)
- But in 2017, Unite underwent three significant shifts First, the company pivoted its business model including a subsequent renaming and rebranding. Simultaneously, the software department went from a monolithic software architecture to a full-blown microservices architecture. Finally, everything moved into the cloud. (View Highlight)
- The company implemented a microservices architecture to change the essential software components of its business quickly. That meant the business contexts started to change much more quickly. Suddenly, we didn’t have “step-by-step” instructions anymore because every report was based on a new concept or product we didn’t even understand the business lingo of. 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)
- The company went from using data sporadically to using data in every major decision. As a result, the value of the information the data team delivered changed. Before, there were a lot of small tasks with small value. Now there were big tasks with big value in a fast-changing environment. (View Highlight)
- These moments- significant changes in the environment around the data team, in the business, in the software department organization, and in the way end users work with data- will create the space and opportunity for a workflow transformation. They may happen slowly and creep up on you, or there might be big bang moments. They might be hard to see or quite apparent, but, no matter how they appear, you must observe them closely and decide to act. (View Highlight)
- 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. (View Highlight)
- 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)
- While we considered a process change inside the team, we also had many conversations about our new business model with top management and the head of analytics. It was clear from these exchanges that this new business model needed to have data infused into every part of the key decision-making positions, and it needed to happen fast. We decided that Option 2 was the only way to achieve our goals. (View Highlight)
- Integrating data into decision-making everywhere was a significant shift. However, to progress on this shift, we had to keep working in one direction, not several disconnected ones. It meant we needed serious direction setting and prioritization. (View Highlight)
- The idea of “Setting a direction, aligning the team” sounds like product management 101. But 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. (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:
- They should be small. You won’t get large changes approved. You only get fast results with quick and, therefore, usually small changes.
- They should still be meaningful so that you can show actual progress. (View Highlight)
- • Implement a regular planning event with all your stakeholders, such as quarterly planning
• Implement a backlog to show off priorities
• Implement a roadmap to communicate strategic focus
• Implement regular but infrequent meetings with key stakeholders to discuss major initiatives
• Communicate your planned new way of working internally. For example, through a blog post
• Propose new work items you come up with yourself that align with the company’s direction (View Highlight)
- By the time we decided to change, 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)
- • 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 outcome was a very different plan for the upcoming quarter. Instead of a long list of dashboards, we reduced our efforts to two significant initiatives. Even better: the stakeholders were on our side, and though some didn’t get any of their projects into the upcoming quarter, they did realize the importance of the work to the company. (View Highlight)
- I recall one key stakeholder I completely cut off for a quarter (and indeed multiple ones) saying, “That sucks, but you’re right; this is the best for the company. We actually will get by. We have workarounds; the salespeople don’t.” (View Highlight)
- In the previous meeting, I had agreed to finish a long list of reports and dashboards, leaving little room to adjust the course. However, this quarter, we were free to adjust as we worked toward a bigger goal. (View Highlight)
- Once we had some early success with moving into a product operating model, I talked to my boss. Over a couple of conversations, we analyzed the approach. My manager and I both realized we needed a vision for the team. So I brainstormed and came up with the following: (View Highlight)
- To help employees make better and faster decisions thanks to data. (View Highlight)
- We could only truly analyze the proposed shift from this point on. This vision clearly showed that the service model wouldn’t work and a product model would be needed (View Highlight)
- couple of questions we dug deep into were:
- Is this vision closely aligned with the company vision?
- Is the vision closely aligned with the department’s work?
- How are we planning to implement this vision?
- Which people are we focusing on to make better decisions?
- Do we need support to pull this off?
- Are we taking all our stakeholders with us with this change?
- How do we make sure we’re keeping our focus up to date? (View Highlight)
- The second insight was more subtle initially, but it was one of our most significant shifts. There is one big question that internal data teams should spend the majority of time on: “Which internal customers are we focusing on?”. (View Highlight)
- Lots of internal users of business intelligence systems, most of whom support decision-makers by providing information from this system to them (and of course, some are decision-makers, but they are smaller in number!). (View Highlight)
- Decision makers themselves also use these systems but always rely on support from analysts and other people to make their decisions. (View Highlight)
- I set up a regular but informal meeting open to all end users. Its purpose was to inform and gather information, but it was never a “planning” event. (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)
- users evolved over time. Here are some of the strategies we tried:
- Have demo days; we had them bi-weekly
- Write a newsletter; we did a quarterly one
- Run surveys; we did one with every newsletter
- Establish a “community of data practice”; we did one every other week
- Open up specific Slack channels for questions
- Have a public clear and visible nearsighted roadmap. (View Highlight)
- Slowly, we learned the key ingredients to great product-oriented data work at our company:
- a clear vision,
- big chunks of work that have a visible and understandable value to the company,
- Embracing the duality of internal customers and communicating with both groups (a lot!),
- a focus on the high-level decision-makers when it comes to understanding customers.
We went through this process and transformed how the company worked with data. This change was only possible because we iterated.
- We needed to understand first why our team had a service model before understanding what had changed.
- We could only get our first change in our work process approved because of that understanding. (View Highlight)
- We could only start the large-scale change towards a product model by showing how well the tiny change worked.
3. We could only succeed with the transformation by constantly analyzing and learning.
This step-by-step approach underlies our transformation; you will need it, too, if you want to make this transition work. (View Highlight)