How to Use the Software Product Canvas:
The Software Product canvas is meant to be, primarily, a vehicle for creating focus, communication and clarity for a new software concept. It could be used after you have done your product strategy and/or lean canvas. At this early concept stage you can use the canvas to capture the key goals for the software, and most importantly begin to define what the app will do using the method of story mapping. This allows you to have a conversation with your prototyping team to better communicate what the software should do. To make this more understandable, I'm going to use our hypothetical example of a new software app which will be a new 'location' based app to connect people to other people around them - a community app to connect you with your neighbors for instance.
Step 1: Success Metrics: You should start from the top-right and define the 'Success Metrics' - how are we going to measure if this version of our software is successful? What are the business goals? The metrics might be revenue, or just numbers of downloads for instance..
Step 2 & 3: Product Vision and Customer Persona: Here we will state the Product Vision and who the main target group is - the Customer Persona. The Product Vision should be 'big' enough to think beyond just the first version, and the Customer Persona should clearly state who is the main customer and what problems they have.
Step 4: MVP - Version 1: Identify the 3-5 key Product Features/Goals that we are looking to achieve in our first /MVP release (the Minimal Viable Product). In our app example Version 1 the key goals would be to 'Identify your current location and show who is nearby, create a basic profile and communicate with their email address'. This step helps you to put a boundary/scope around your initial version of a product.
Step 5: Future Releases: Here you can list out the other great ideas you have for future versions of your product! At this point we are not committing to these ideas, since many of them will change when you get more customer feedback, but they help to communicate to your team what could be done 'later' and provide a good 'parking lot' for all those great ideas.
Step 6: Story Map: Now it's time to get clear on what the app will do for the current MVP/Version 1. A powerful technique for defining the scope and purpose of software is to use the concept of Story Mapping. Click here to learn more about this concept. In our canvas, we simplify this by asking you to identify four main steps (think process steps) that the app will enable the user to do. We then ask you to identify Activities within each Step that helps to define in more detail what the user does (think tasks/outcomes). By working through your first four steps, and the corresponding activities, you will become much clearer (as will your team) on the scope and functions of the software and this will sharpen your focus on what this version of the product should do. In our example, I have identified four 'Steps' that the software should do to support the user in achieving their goals of meeting new people. My four steps are: 1) Create my profile, 2) Display people near me, 3) Request to Chat 4) Chat with People.
As you can see these four steps reflect the 'process' and the sub-activities explain the steps in more detail (tasks/outcomes). See the completed canvas below.. You will also now understand that the canvas should be constantly updated. For example, in our step 4, we say 'Chat with People' and one of the methods for the first version of our app is 'Establish chat via Email'. This is obviously a quick and simple way to prove the concept of the app. Future versions of the app might change the chat mechanism from 'email' to a 'real time chat' interface, but this will still be in step 4, just a future iteration of the app and a better way to do the task and achieve the outcome.
Step 7,8: Revenue and Learning. Finally it is helpful to complete your thinking and identify how you think revenue will be generated by the app and what assumptions or learnings you are looking to identify through the creation of the app.
Some More Thoughts:
Like all other canvas discussions, this is not meant to be perfectly completed - especially for the first go around. The purpose of the canvas is to initiate and frame a discussion so that at the end of the session you and the whole team have much better clarity about what a first version of the app might look like. Most importantly, the 'Steps' should not change drastically over time, but the Activities can get more detailed or better over time. If the steps change significantly then that means the whole user-flow / process is changing - which can occur of course too.
The benefit of completing the Software Product canvas is that now you, your customer, client and/or design team will have a better group understanding of the project. This will help you to make changes at the start, even before any prototype has been designed, helping you to save money and time, and get a better first prototype. In my experience, it's very rare for a graphic designer to engage with you at this level of detail before creating an app prototype design. Usually you will convey your idea in some simple sketch and then spend a series of conversations 'building out the concept'. The Software Product canvas forces you to do some of this thinking first, allowing you to get to a better first prototype faster by thinking through the critical business and process foundations of the app.
Finally, another benefit of the canvas is that it allows you and your team to identify the 'minimum' product that needs to be developed, which helps your technology team to think about the technology effort required. At this point if you like you can also create a Technology Product canvas (see here). This will help you to drill down further into the product development. You can use the Technology Product canvas to lay out your Product Vision over a couple of releases, and then have a high level technical discussion about what it will take to create each version. Doing this early on in your product development process can help you to 'work backwards' in some cases from a technology perspective. Laying out the technology requirements can help you to identify future needs, and this can in some cases make you select different initial technology choices than you might othewise have, helping you to better technologies that scale and grow with you to support your longer term vision and perhaps reducing double-work.
If you think that you need to modify the canvas to better suit your needs, please do. I'd be really interested to hear your feedback about how we can improve this 'release' of the Software Product Canvas!
Here is a completed example of the Software Product canvas based on our hypothetical app example above: