Identifying Taxonomy Needs
With that said, the best practical way to think about building a taxonomy is establishing a shared language. If you’re talking about the same thing, it turns out to be pretty convenient to be using the same word. I’ve built and integrated taxonomies in the past, but it’s always been retroactive. This can take a massive effort and it always feels a little too late. By the time a company feels the pain that a lack of structure and loose classification brings, you have to work through all of the pieces that are causing that pain. Taxonomies fall into an odd category from an ownership standpoint, a common struggle for organizations large enough to really feel the pain of ambiguous ownership.
I’ve been curious about how difficult it would be to adopt at a time that feels a little too early. It should come with its own holster of issues, assumptions, etc., but if there’s a way to embrace it early and embed into business process, I expect it could make taxonomy adherence an integral part of doing a job well and incredibly easy to pivot in the future where iterations are needed.
But, half-hazardly incorporating process and structure is a quick way to get nothing done. Given that I know the utilization of taxonomies is generally advantageous, I want to start with how and where taxonomy usage could be helpful in the short and long-term from a business perspective and then build appropriately. Let’s go!
Why solve a problem that doesn’t exist?
Like I mentioned, I’ve worked with taxonomies quite a bit in my career so I’ve seen the value they bring and the pain the lack of classification (or not very thoughtful classification) also brings. However, when building from scratch and trying to move fast it’s easy to see something like this as tedious and “not very agile”.
The problem we are trying to solve is one that doesn’t exist because it’s easily hidden by humans inadvertently acting as operational efficiency buffers. It’s in the weeds of Operations and while the inefficiencies accumulate they continue to be easily categorized as one-off scenarios. Meanwhile, remember that we work with humans (mostly) and somewhere along the lines these humans will likely start building their own taxonomies in silos. At scale, they need something to keep themselves and their team organized. But, there’s no reason that how they classify will be the same as another team - why would they? They will classify in a way that helps them get their job done in the most efficient manner, likely with their job function as key dimension. Things as simple as choosing to call something a different name or choosing to ignore a dimension because it doesn’t pertain to the work being delivered adds to the complexity of retroactively embracing a common language.
If you are starting to feeling the pain of not having a taxonomy, that likely means you now have work that is dependent, or at minimum, would benefit from it. You may have worked with various teams in the past where you had a similar request to two different teams, such as a data request, and one team was able to get you what you needed in 5 minutes while another team had to put your request on a backlog with a message back that goes something like, “Unfortunately, we don’t have a good way to get you that so we’ll need to put it together manually/create a custom query” and now your seemingly simple request has created weeks of manual work (that likely won’t be a long-term solution and would need to be done each time the request is made) and then you’re being pulled into scoping conversations of business value so that they can justify a long-term solution. And since you thought it was an easy ask, your original request may not even be the full extent of what you needed! It becomes a conversation about value despite the huge disparity in operational cost and effort for the same request to the two different teams - a key part of any value generation. So, being purposeful about structure sheds long-term cost in a massive way and reduces the complexity and accessibility of requests all across your company.
As I previously mentioned, I believe the best way to think about creating taxonomies is creating a shared language. Most differing job functions will care about different dimensions, and that’s fine, but when they do care about the same dimension, we want to make sure it’s referred to similarly. If there’s a business incentive to know something, how can we structure business process to accommodate that need? It requires you to think outside of your function and understand the teams dependent on the work that you do.
If you’re working in Sales, the quality of your CRM data can have a direct impact on how quickly Accounting can determine your comp rates.
If you’re working in Service, the quality of your CSM data can have a direct impact on how much you need to keep Sales in the loop.
If you’re working in Product, the quality of your architecture has a direct impact on velocity, query cost, and how much you need to work with Service to understand market fit, adoption, or even just client feedback.
That’s a very long way of saying that I think it’s worth risking a bit of overbuilt taxonomy in business process for the exact reason it’s hard and tempting to ignore - you never know how or when it can save you in the future.
Bringing Context to Delivery
To get into building, I need to first address what I’m doing, consider the systems that will be involved to do it, and then consider what dimensions the various stakeholders would care about. Keep in mind, the most important stakeholder is the consumer. The below is all internal considerations but in view of appeasing their needs.
Overall, I’ll probably have 4 big buckets of deliverables for this website:
Content
Resources
Projects
Services
And for these deliverables, I’ll need applications that support:
Website
Storage
Computing
Security
Management
Measurement
Communication
Accounting
Client Relationship Management / Client Support Management
I made these up, but they roughly cover the key touchpoints of digital business process. You could view them as a business-oriented look at the systems that make up your business architecture.
To bring the business context to these applications, I need to consider the core functions that a typical organization takes on:
Product Development
Sales
Marketing
Operations
Finance
Human Resources
Customer Service
Quality Assurance
Information Technology
I didn’t make these up, but someone did at some point in time. Again, it’s not an exhaustive list and you could probably argue that considering functions instead of focusing solely on the problem is why we get these mixed incentives in the first place, but we’re not trying to reinvent business (yet).
Now, this isn’t to say I need to fully understand or vet each of these but it’s a good way to think about who might be interested in the pieces and what they might care about for each piece. Of course, each stakeholder won’t care about each piece but as long as they have quick access to what they care about, things will likely go well enough. We can loop through each of the stakeholders and talk about each delivery to understand what they might want to do with the information.
As a Consumer of Content, Resources, Projects, and Services, I want to find the deliveries that are relevant to me and my needs so that I can glean value from the website.
As a Product Development stakeholder, I want to know what Content and Resources are helpful so that I can build Projects and Services. I also want to know how Projects and Resources are doing so that I can iterate.
As a Sales stakeholder, I want to know what Content and Resources are helpful so that I can sell Projects and Services accordingly. I also want to know who is reading the content and using Projects and Services and how they are doing so that I can provide customer feedback.
As a Marketing stakeholder, I want to know how people are using the website and who is using the content, resources, projects, and services so that I can build marketing strategy around these offerings.
As an Operations stakeholder, I want to minimize duplicative efforts and streamline the creation of content, resources, projects, and services. When possible, I want to automate tedious tasks related to each, and I want to make sure effort isn’t wasted creating things of little value.
As a Finance stakeholder, I want to itemize costs and sales associated with each effort so that I can know what is working and forecast accurately. I also want to know about market dimensions that could influence the forecast.
As a Human Resources stakeholder, I want the website to be informative and information easily accessible so that candidates are well informed and I can build necessary training resources with ease.
As a Customer Service stakeholder, I want to be able to find resources with ease and know the success of projects and services and who they were successful for so that I can work quickly, not waste time guiding clients through low value needs, and lean into the success of projects.
As a Quality Assurance stakeholder, I want systems in place to easily drill down from a high level to granular view of all deliverables so that I can find inconsistencies or bugs.
As an Information Technology stakeholder, I want to have a clear understanding of the architecture and system utilization so that I can manage security risks and optimize resource usage.
We can’t project out for all needs, but we can match their mental model to some extent and understand how or why something would be helpful. Beyond that, attempting to have structure to accommodate their needs already sets us up for iteration if it falls short. Not in every case, but hopefully in most.
Identifying Key Dimensions
After spending some time, I’ve identified what I believe to be helpful dimensions for building taxonomies that satisfy the needs of our stakeholders for deliverables and applications. I may revise this later to include some of my brainstorming if it’s helpful (or a follow up post - content! content! content!) and while I have more detailed definitions to establish guardrails for myself, here’s the general idea:
Website Structure - How the website can be navigated vertically and horizontally.
Content Type - The deliverable that’s being produced.
Business Function - Core functions an organization normally performs.
Subject Area - Concept-level classification that the content helps with.
Operation - Task-level classification that the content helps with.
Programming Language - If applicable, any programming language needs to assist with the Operation.
Applications - If applicable, any applications used to assist with the Operation.
Asset Taxonomy - File structure and naming conventions for supporting assets.
Service Type - Forward looking acknowledgement that services provided won’t neatly fall into the above categories. May remove later if that proves to be incorrect.
Something I found really helpful when building up and filtering down the dimensions was to see if I could summarize the work through a standard user story template (learn more here) and defining the relationships between the dimensions for the deliverable (similar to a knowledge graph). Using this piece of content as an example, you could describe it through the taxonomy:
Relational Classification - Community Content Type about Content Management through Developing Taxonomies on Squarespace for Sales, Marketing, Product Development, and Customer Service
User Story Template - As a {Business Function}, {Subject Area} I want {Content Type}, {Operation}, {Applications Used} So that {Content Type: Value}
Doing this made me rethink how I was structuring the website and prioritized some classifications over others.
After doing this, the only missing element was Asset Taxonomy. This will simply be mapped to our other taxonomies with the inclusion of Asset Type:
Folder: Mapped to Website Structure
Naming: ShortDescription_Operation_AssetType_Version
What’s Next?
The final step in building out these taxonomies is to make sure that it will be theoretically possible to get our stakeholders what they want. The taxonomies aren’t complete yet, nor do we have a way to implement them, so we’re just talking from a business perspective on IF this information was available, does it check the box? While I’ll save some of the details for my next post, it will require some creative solutioning to make it work but all boxes should be checked.
In the next post I’ll be going through the development of each taxonomy and go through each deliverable to classify where they should be implemented at the application-level. If all goes well, we’ll have a pretty good strategy that meets all of the application and stakeholder needs for now and in the near future.
Thanks for reading.
