I recently started reading about Wardley maps, created by Simon Wardley. His way of visualizing a business strategy is fascinating to me, and there are a bunch of concepts I’m trying to adopt.
In one section of his book, he talks about how to organize teams around different parts of your business strategy. He breaks down teams into three different groups. Pioneers, Settlers, and Town Planners. The simplest way I can describe the groups are that the pioneers turn the intangible into something tangible (new product ideas), the settlers bring a little bit of order to it (specification), and the town planners optimize it for the long haul (optimization). As time goes on, these optimizations create higher order effects, which allows the pioneers to work on the intangible again, and the cycle repeats.
I started to think about if an analytics team could fit in this type of structure. There are obvious parallels in my mind, but I wonder whether it would be a net improvement.
Many data analytics teams are structured like below. They are a central team within an organization, with different data analysts working as a business partner to other teams within the business.
One analyst might be designated to sales, one might be designated to product, and another may work primarily with the customer support team. The most effective approach I’ve seen for this is for the data analyst to become T-shaped. A T-shaped person is someone who has deep knowledge and skill in one area, but also has decent knowledge and skills in a variety of supporting areas, since that might impact their work.
For an analyst dedicated to one specific team, their responsibilities may run the gamut for anything related to that team. Let’s use a product data analyst at a SaaS company as an example. It’s likely they’ll be involved in analyzing product metrics around acquisition, conversion, retention, and revenue. To do this effectively, they’ll need to have knowledge around ad hoc data analysis, data reporting, A/B testing, predictive modeling, and maybe a few other technical areas.
That’s a lot to cover. Some people may thrive in that type of environment. They may want to be involved in every stage and every aspect of a product. For those who don’t thrive in that type of environment, what would a PST alternative would look like for this?
The biggest difference is that data analysts would now work on projects that spanned multiple teams. Rather than being the go-to person for a specific team, they would be the go-to person for specific stages of a project.
Off the top of my head, I’m imagining that pioneers would work on ad hoc analyses, have a sense for market trends, analyze external data, and maybe use some programming to scrap and clean messy data. They would be the first line in answering new questions for a business.
Once the pioneers have done their job and it’s possible to make sense of their work, that’s when settlers would come in. They may work to better understand what the pioneers have done. That would involve running more formal experiments via A/B or multivariate testing, building some ad hoc reports, and even building some dashboards for stakeholders to use. Finally, the town planners would come in to optimize this work for the long run. Once there’s enough data, predictive models can be built, and more nuanced ad hoc analysis can be done to find small improvements in the data. Eventually, the pioneers can use the insights from town planners’ work new projects, and the cycle starts over again.
This seems like a more streamlined process that could be successful. How could it not? Assembly lines became popular for a reason.
As I thought through this more, I started thinking about the pros and cons of this approach.
These are just a few quick thoughts on using a PST structure. As I continue through Simon’s book, I’m sure more thoughts related to this will come to mind.
If you have any additional thoughts on using a PST structure for any team, I’d love to hear from you. I’m most active on twitter @mattpupa, but will also respond to emails as well.