While defining a software product, it is inevitable that the question “For whom the software is built?” emerge in the discussion circle, making everybody pause for a moment. We know targeting the right users is vital in building the right software. Without keeping the users in mind, no matter how good a software is developed, it is never good in the way that truly works.
To aid you along the software outsourcing process, we’ve created the How To Outsource Software Development: Axon Active Edition guide series which gives you the big picture of the entire process and systematizes everything in easy-to-follow steps.
In this second article of the series, we will walk you through the two most commonly-adopted techniques nowadays that help target the right users–Persona Canvas and User Stories, as well as handy tips provided by experts in the field from Axon Active and leading software experts around the world.
Reproduced from: Anastasiya Markvarde 2019 interview with Brant Cooper
Introduction
When we plan out our agenda to develop new software or add new functionality to an existing piece, it’s important to make sure our assumptions and hypotheses about every feature of novelty are proven worthwhile and legit.
“How we discover whether our assumptions are true; how we measure the customers’ behaviors; and how we decide whether to pivot our idea, keep on (persevere), or iterate (test again) are to use empathy, experiments, and evidence.”
– Brant Cooper and Patrick Vlaskovits, The Lean Entrepreneur
The definition of empathy, experiments, and evidence, according to the authors, are defined below.
Empathy: Understanding our customers deeply: their pains, passions, and desires. Developing insights.
Experimentation: Translating insights into action. Reducing risks through assumption testing.
Evidence: Making decisions quickly based on insights and actual customer behavior.
Empathy: Go out to the world and home in on your users
There is the famous story of a Toyota manager who went all the way on his car to observe the perspective of every Toyota user in all 50 US states, 13 Canadian provinces, and the entire Mexico territory. All to get to know better and all the more precisely about the user feedback!
This way of thinking had gotten Toyota a whopping “60% higher” in 2004 sales figures compared to that of 2003.
“You cannot be sure you really understand any part of any business problem unless you go and see for yourself firsthand. It is unacceptable to take anything for granted or to rely on the reports of others.”
– Eric Ries, The Lean Startup
Depending on your business size, you can do more or less the same to get to know about your users. Getting in touch with your existing or potential users early on will expose which assumptions about your software you need to have usability testing done asap.
If you’re developing new features for existing software, it means you’ve been through every possible stage of the software development at least once. You know too well that the vision, scope, and expected outcomes at the beginning of every development cycle are mostly – if not all, based on your assumptions.
To validate your assumptions and really get the real picture of your users, you are to muster up your courage, fling the door open, and literally go out of the building – even beyond the country like that Toyota manager, in order to interact with your users. And then you are to jot down as much information as possible.
It is one of the best and most valid ways you can really put yourself in the users’ shoes.
“We find that the most difficult part of having these types of conversations with prospective customers comes from the inability to succinctly describe the problems they face.”
“To truly understand a problem, you should not propose a solution, at least not initially. That’s because the reaction you get will be to the solution and not to whether the problem really exists.”
– Brant Cooper and Patrick Vlaskovits, The Lean Entrepreneur
First tool: Persona canvas
To brainstorm ideas about your users and their situations, and to even give you further hints on how you can create a brand new or re-design your current piece of software in a way that can really solve user problems, one way you can use is Persona Canvas.
Persona is another term for your group of end-users. A piece of software, as a matter of fact, can solve the problems of more than one user group. Hence persona can come in the plural, too, as personas.
Templates are shown below (followed by examples).
Template 1
Template 2
Reproduced from Erik van der Pluijm (2019)
Although we’re giving you two canvas templates, they’re just slightly different in design.
Second tool: User stories
Another way to do this is to make use of user stories. User stories answer the questions:
Who (needs a particular feature in a software)
What (feature do your users wish to have)
Why (you should build this feature into your software)
A grand user story template looks like the following:
As a WHO, I want WHAT so that WHY.
To do this, on separate post-it notes, you will name the different types of users and write a little bit about what they want:
On the first post-it:
As a USER 1, I want SOFTWARE FEATURE 1 so that USER BENEFIT 1.
On the second:
As a USER 1, I want SOFTWARE FEATURE 2 so that USER BENEFIT 2.
The list will go on until you run out of ideas for user 1. Then, you continue for user 2, user 3, and so on.
The point of using post-its is that it will help you arrange and re-arrange all the cards at ease.
For example:
As a user of the ABC banking mobile app, I want to transfer my money online to others in a safe and fast manner so that I can save time going to the bank.
As a user of the ABC banking mobile app, I want to conduct banking transactions swiftly with an easy-to-navigate interface so that I can save time using the app.
Be careful!
It’s quite easy to go down the rabbit hole if the user spectrum is too deep and too broad.
“One of the tough realities about software development is that there’s always more to build than we have time and money for. So the goal should never be to build it all. The goal is to minimize the amount we build.”
– Jeff Paton, User Story Mapping
~~~
“Every market has multiple personas, and each persona might have multiple “use cases” – in other words, ways of using the product. Ideally, you design your product around one persona with the most compelling use case.”
– Brant Cooper and Patrick Vlaskovits, The Lean Entrepreneur
Try out describing a handful of different user groups, or personas, on post-it notes first. Arrange and re-arrange them. And naturally, the most potential group will naturally emerge with higher stacks of cards. That group will be your focus.
It’s no doubt that it will be challenging (but extremely rewarding) if you’re trying to figure out your target users this way for the first time. Getting to know your users firsthand will get your software off to a good start and more likely end it on a high note in the market.
Meanwhile, for current software owners out there: You’ve done the user research at least once before. You can somewhat make out the profiles of existing users, and somehow you know these profiles cannot be taken for granted.
The market continually changes, and users shift their tastes all the time, which explains the reason to develop new software features to satisfy your existing or potential users. For this, it’s even more convincing that you should put them into perspective again – using these tools.
“Your job is not to be faithful to your product, value, and market assumptions, but rather to validate or invalidate them.”
– Steve Blank, The Four Steps to the Epiphany, in The Lean Entrepreneur
By using these tools together, you can understand your current groups of users better, all while seeing new set(s) of users emerge.
Some of the questions that will guide your learning during the interaction with your users
What are the top one to three pains or passions within the context of your product/solution proposal
How do people currently deal with their pains? Why do the existing workarounds/solutions fall short?
What is the cost of the problem?
How deeply is the pain or passion felt?
What is the primary obstacle to converting? Why would users decide not to buy?
What is the customers’ practice when buying other related (or semirelated, not necessarily competitive) products? In other words, how do customers expect to be marketed and sold to?
Do your customers view your solution ideas as belonging to a new market? In other words, if they can instantly compare it to other solutions out there, it’s not a new market.
Do your customers currently have the necessary environment to successfully incorporate your product into their existing workflow or their daily lives?
Can they envision your product existing in their lives, and, if so, under what conditions?
Would they pay $1 for it? $1 million?
– Brant Cooper and Patrick Vlaskovits, The Lean Entrepreneur
Experiment & Evidence: Create the closest version of your product & get your users’ feedback asap
After gathering all data from the users, the next step is to create the closest version of the new software or the functionality that will be built into your software. However, if you’ve never done this during the development process of your software in the past, now is the time.
To make it work, it is not just merely building different parts separately one by one, but to build the whole thing from the simplest version with minimum sets of all the necessary useable features. Later these sets of features can be developed into a more hybrid version as you keep the user feedback coming in.
By keeping coming back to your users for their feedback as soon as a version of your product is produced, you allow yourself to have latest user feedback on a frequent and continuous basis.
These pieces of feedback will help you improve your software much more efficiently and effectively, leaving almost no room for waste in time, labor, and all other called-for resources. Plus, you are likely to earn more positive user feedback from the initial stages of software development down to the desired end.
Bonus point to broaden your horizon
The key benefit of user stories: They increase a sense of shared understanding about your product/project with your development team.
“Obviously by saying ‘As such-and-such, I want…’ you can see how the person’s mind goes instantly to imagining he or she is a such-and-such.”
– Mike Cohn, Advantages of The “As a user, I want” User Story Template.
This is particularly true in the offshore software development context, especially when you decide to outsource and speak a totally different tongue with your development team.
User stories help you (as a client) to initiate your conversations about your vision and ideas for a piece of software with your development team. If you think communication is easy, think again.
The following illustration shows how easy it can be to inadequately and unclearly convey your message to another party:
Recreated from Jeff Patton (2014)
At this point, it’s important that everybody has to speak up to see if their understanding about a feature of your software is correct through the use of drawings, post-its, and so on – all to get the right picture of the feature.
Feel free to discuss your ideas with your team until the ideas get improved and well-understood by everyone in the team.
Summary
It is the most important thing to understand your users firsthand and never rely on outdated data or other people’s opinions, or worst, your assumptions, about them. From the right understanding of your users and with your assumptions tested with the tools provided in the article, you can productively communicate your vision with your team, e.g. software outsourcing team. We hope the article has actually broadened your horizon and give you a good start towards defining your target users.