When we’re building a product for people, we are hopefully offering them something that helps them with the things they want or need. Our product will have things that it can do, and using these will help our users meet their goals. Within AgileLabs we call the things that our product can do “Capabilities”.
We describe a Capability in terms or a thing that the product can (or will be able to) help the user do. This is something from the user’s problem domain, where we will think of and deliver a possible solution. For example, users of AgileLabs probably have a need to have a clear picture of who is collaborating on what at the moment; the solution we offer to meet that need are Goals. It’s important to notice that it’s not the only possible solution, we merely have a hypothesis that this solution can meet the need at this stage and will need to test this by getting it in front of people and getting feedback.
In its simplest form, a Capability is either met or not. Right now, can a user use our product to get what they need? This might not be in the most elegant possible way, but one of the key tenets of lean and agile product delivery is to get from “no” to “yes” as quickly as we can.
You may have seen this picture before, in various forms. In this example, we think of a customer who needs to “be able to get around”. We could, and perhaps would under some methodologies, start by making a single wheel, then a chassis, then adding a body, then delivering a car. The problem here is that the user’s needs are not met until right at the end. The whole time from discovering the need until final delivery of the finished product, the user has nothing. Applying lean and agile techniques we might try something more along the lines of the second approach, where we try to deliver the simplest thing we can as soon as possible, and then iterate to make it nicer.
In AgileLabs, we describe the state of a Capability in 2 main parts: first, is the capability met, and secondly, how nice is it? In the example we have in the picture, the skateboard technically meets the need, but it’s not very nice – we then take small steps to make it nicer, based on feedback and learning more about the user’s needs. A really powerful side-effect of this is that often we discover that the thing we end up building has evolved and may look very different to what we would have set out to build at the start.
A product is likely to have many capabilities, and choosing what order to deliver or improve them in can be quite unclear! To help clarify what the options are, we might ask questions like:
- What is the most valuable unmet capability?
- What is the least nice met capability?
- Should we focus on making 1 key area as nice as possible or on meeting many needs?
The question of what we should work on next is very much dependent on context and strategy; there certainly is no universal “right” answer. Our aim with Capabilities in AgileLabs is to give a way to collect the variables and see some of the possibilities in a way that the team can easily share an understanding of, and have a good conversation that informs these decisions.
Hey there! I’ve been reading your weblog for a while now and finally got the bravery to go ahead and give you a shout out from Kingwood Texas! Just wanted to tell you keep up the great work!