#5 - What are a products "skills"?
A (potentially) new way to think about product prioritisation, roadmaps & outcomes
The product team I work on here at Lime has been experimenting for the past few months with using a new method (at least for us) for thinking about product development, prioritisation, roadmaps and delivering on customer outcomes.
I’ll preface this post by stating that this is a new and ongoing experiment for us. It’s absolutely not a perfect framework and we’re still trying to tweak how we use it internally. In many ways this post is me grappling with the concept and trying to better define the boundaries of what it is, and what it should be used for.
Lastly, my colleagues Magnus Fagerlund and Filip Arenbo have been the real drivers of this initiative, but I’m taking the liberty of digging into it in this post . Credit for the original spark of the idea must also go to the Mozilla engineering team, who wrote about the Product Skills concept in a technical blogpost last year.
Our experiment: Product-Skills
The basic idea is that a product has a number of Skills in which the product is or should be proficient.
The more proficient the product in its set of skills, the more value the product should theoretically deliver to a user.
Product development should map to those Skills, product packaging/marketing should reflect how those Skills deliver customer value and communication to stakeholders can be filtered through these Skills.
Our hypothesis is that Skills will help us:
Keep our roadmaps at a high level
Stay focused on customer value & outcomes (rather than features)
Help stakeholders understand what we’re doing and why
What Skills does Excel have? What Skills does Slack have?
Note: These are just my impressions of the core skills of these products as a user. Perhaps the internal teams think very differently about their products capabilities. If by any crazy chance you’re reading this and work on a product below (haha!) - I’d love to hear from you.
Excel: "Familiar", "Flexible", “Extendable”
The beautiful thing about Excel is that it’s instantly familiar to everyone. Cells, rows and columns. Open Excel, start typing. Yes, there are a lot of power features, but for a beginner, hoping into Excel likely isn’t intimidating. In addition, Excel’s flexibility means it can be used for so many things. Basic databases, project plans, budgets. Finally, Excel is extendable. Macros, External Data Sources and plugins mean users can tweak Excel to their own use case.
Slack: "Searchable", "Knowledgable", “Integrable”
When Slack first launched, the company was SUPER clear on core skills that made it so unique at the time. “All your companies knowledge, indexed and searchable”. When a new employee joins a company, they don’t arrive to an empty inbox, instead they have access to a huge amount of knowledge, conversation history and context via Slack. Lastly, like Excel, Slack’s integration capabilities and vast App Directory is a core skill that really helped Slack make a splash when it launched a few years back.
How does Skills differ from Themes?
Themes is all the rage now in product development circles. Here’s how ProductPlan’s Jim Senick defines describes Product Themes.
In their simplest form, themes are groupings of similar features, epics or initiatives. Ideally, themes describe customer value – what customers are going to be receiving or the job that you’ll help them accomplish.
Themes help keep your roadmap at a high level, especially for those long-term, fuzzier initiatives. One benefit is that you can switch features in and out of the theme without significantly affecting the roadmap. It’s a better way to keep executives and stakeholders on the same page and focused on the big picture.
Even if Skills and Themes on the surface seem similar, we do believe there are some key differences and that Skills provides an even more structured way of helping product teams focus on the real goals.
The key difference: The Themes They Are A Changin’
We don’t see our products Skills changing, at least for a while. We think of Skills as the “always true” backbone of our product strategy and value proposition. Whilst the themes we focus on should change based on market dynamics (new technology, new competitors, new products, new markets etc) - a products core set of Skills should stay the same.
This should help us not lose track of what really makes our product appealing, competitive and somewhat unique to us. Whilst it’s easy to get caught up in the latest product trends, or to blindly follow a competitor - Skills should act as a guiding star for the product team. If we’re not mapping work to one of the core Skills - it should at least elicit a good discussion as to whether it’s really worth focusing on.
The Skills Workflow
Unlike a Skill, a theme is something the team focuses on for a shorter period of time. It could be the focus of a sprint, but could equally be connected to a goal. A product theme that the team focuses on should generate one of more customer outcomes, and of course these outcomes are delivered via measurable product output, often in the form of features, bug fixes etc.
The value of investing in Skills over time
We see building and investing in our Skills almost like leveling-up. The idea being that by doing so - you can build more and more strength and reliability into a products core offering to its customers. If customers/users choose a product based on its underlying skills (reliability, searchable, extendability, collaborative etc) - then investing in leveling-up those Skills makes total sense. We see it as a way of building long-term competitive advantage and sustainability into our product strategy.
Whilst product trends come and go, core underlying strengths should never go out of fashion. Now, those Skills may need to be re-trained from time to time based on tectonic shifts in either user behaviour, consumer expectations or technology - but the definition of the Skill shouldn’t need to change - simply the implementation of becoming proficient in it.
A product that was “Extendable” in 2003 (I’m looking at you SOAP….) looks fairly in-extendable by today’s standards, yet a company may manage to stick with it’s core Skill and continuously upgrade the means by which the product delivers on it - i.e. REST APIs, Zapier Integrations, App Store’s etc.
A Risk: Contradictory Skills
As my colleague Filip mentioned when we were discussing this the other day:
“It’s hard to be an olympic weightlifter and run marathons”
A classic software dilemma is trying to build products that aim to be Powerful, Flexible and Simple - all at the same time. One risk we see with the Skills concept is how easy it is to create and adopt contradictory skills. Although, on the other hand - mapping work to Skills could also help to identify any potential misbalance between the Skills. For example, for all work dedicated to “Flexibility”, the team should make sure that the “Simplicity” Skill is getting enough love, time and attention from the product team. Skills could therefore be used as a balance-function to ensure teams don’t focus too much on one Skill and ignore another.
Example: the Skills of our core product - Lime CRM
To add some context to how we think about Skills, here is the skill-set for our core product Lime CRM.
I’ve enjoyed implementing the Skills concept internally and I do believe there is a lot of value in constantly exploring how better to link daily/weekly product work to higher level concepts, such as Themes and Skills. To keep the team focused on the real goals, to improve communication with stakeholders and to ensure that roadmaps aren’t constantly failing us.
I’d love to hear your thoughts on Product Skills, hit me up on Twitter or leave a comment below.
Until next time,