Why Thematic Goals make sense
This is just a page to explain the benefit of an organization having a thematic goal versus not having one.
So imagine we were making an IT solution for managing say summer camps. Basically our solution is an application with lots of database tables and forms that our customers would be using to manage the processes that they have around managing all the admin processes associated with summer camps.
So without a thematic goal to focus the organization these are things I would expect to see:
Customer service reps would receive a lot of anecdotal complaints from customers about various shortcomings in the software to address specific work flow problems each customer has.
Development generally has a hard time making head or tail of the requests and often have trouble understanding the underlying problems, new features which are developed often don’t solve the problems that customers want to solve - even when a feature is delivered to spec as the customer asked for it
Why is this?
Well in my opinion, to go beyond trivial needs problem solving and instead to solving things at a fundamental level, we require deep understanding. If attention is scattered across many many different functions of the software then it’s not possible for anyone - customers, customer service reps or developers - to obtain the deep understanding required to solve the problems in a fundamentally game changing way.
To solve difficult problems one needs to accept that it will take a lot of communication, and that there is going to be trial and error and re-work required to make a lasting deep impact in creating value.
This is where a thematic goal can really help.
Let’s say for sake of argument that such a company were to agree as a team the entire company would focus for six months on trying to completely solve the problems around the enrolment processes. So how would that translate for everyone?
For customer service people it means re-directing customer conversations from other areas that might like to see improvements to instead drive those conversations all around enrolment processes. This then becomes a source of ideas around how the software could be improved to improve these processes. Ideally with enough conversations common themes and patterns would emerge from these conversations.
Development could be focused on trying out some of these ideas, partnering with the customer facing team to get customers to test drive the ideas and figure out which ones work and which ones don’t.
Inevitably there is going a be a fair amount of rework required - but with sustained focus over time all the teams in the company end up with a deep understanding of all the problems in the enrolment process. This is important because to create value for customers it’s not just about the software having the features - but also having the talent, and knowledge to share that understanding with customers so that they can benefit from this and actually overhaul and improve their processes to create real world measurable impact in their businesses. That translates into lots of webinars and information related to this functionality - which helps with marketing and customer acquisition.
An organization that gets good at this process could methodically renovate each part of their software and create compelling value in each of the areas - over time this would add up to a compelling competitive advantage.
Â