Using a PST structure for an Analytics team

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.

Pros

1. Data analysts would be better aligned with their attitude and their natural wiring. This would have the biggest impact, pro or con, in my opinion. Knowing what makes individuals tick, and putting them in a position to succeed based off of that knowledge is more rare than it should be. Some people have natural curiosities about exploring new ideas, some want to build things, and some want to organize things. If data analysts did more work around their interests, they’re likely to be more motivated and more productive.
2. Data analysts would gain specialized knowledge. Think about muscle memory. The more you do something, the easier it becomes and the more natural it feels. The same concept applies here. This goes back to the assembly line comment I made before. If you allow people to become specialized in a certain area, they’ll like perform way better than they did before.
3. Data analysts would gain broader knowledge of products. There is an argument against specialization. You run the risk of employees getting burnt out because they are doing the exact same thing over and over. The good thing about an analytics team operating in a PST structure is that this risk in minimized in many cases. Because companies have so many different teams that require analytics help, data analysts will gain broader knowledge of the company. Even though a town planner will always be working on optimization, there could be so many different approaches and projects to optimize.
4. There would be more clarity around data and metrics. One of the biggest issues with analytics is when metrics don’t match up. It can happen in many cases, but the worst may be presenting something to leadership and the reaction is “I see ‘metric X’ as something different”. Not only can this cause distrust for an analytics team, but often times there’s so much time spent investigating how metrics were calculated, that takes away from doing more impactful work. In a centralized analytics team, there’s risk of this happening with every analyst who does work for different team. They’ll all have their nuances, and those nuances aren’t always shared with teammates. In a PST approach, clarity around metrics could be assigned to either settlers or town planners. They’ll have a better view of the entire metric landscape, and can bring up issues before they turn into bigger problems.

Cons

1. There’s no longer one go-to person for each stakeholder team. This is one of the best aspects of a centralized analytics team. Without it, duplicate requests and analyses can become commonplace, which is disaster. In his book on Wardley maps, Simon mentioned having a chief pioneer, a chief settler, and a chief town planner. Although this does simplify the communication channels, it’s still not as ideal as having one data analyst per team.
2. There won’t always be consistent work in each of the PST phases. This will depend on the type of company as well as the maturity of the company. For an enterprise, this may not be a big deal. They are always managing their core products while trying to develop new offerings. However, for a smaller company, they may have a singular focus. If a startup is still trying to reach product market fit and get as many customers as possible, they won’t have the same resources to put into building new products.
3. Data analysts won’t get a complete view of the product lifecycle. This goes back to the individual wiring I mentioned earlier in this post. For data analysts who want to be involved in every aspect of a product’s lifecycle, they may feel they are missing out if their focus is too narrow.

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.

‍