5 simple behaviours that lead to great products
If you are a designer, product manager, or engineer that participates in software development, here are five really basic things that your teams can do that will guarantee more value gets delivered to the people who use your products.
1. Identify the people you want to help
Be very intentional about identifying the persona(s) you are solving for. If you have a set of defined personas for your team, choose which ones you are focussed on, and in the case of B2B make sure this includes both the buyer persona, and also the user persona. If you do not have personas, take time to describe the type of user you are targetting in enough detail that allows you to go identify some real world people that match that description.
2. Spend time talking to those people
Now that you can specifically identify who you are solving for. GO TALK TO THEM. A good rule of thumb is to try and talk to 8–10 representatives of each persona and get them to talk about their experience as it relates to the thing you want to create/solve. Do not ask them what they want, but rather get them talking about their experience in using the thing you want to improve. Your goal here is to better understand what they NEED vs what they tell you they WANT.
3. Document and prioritize the unmet needs
After talking to the people above, you will surely have a better idea of what problems you need to solve with your solution. Write these problem statements down and ideally they should be stated in terms of customer outcomes — bonus points if you can identity the behaviours that you will see if you are successful.
4. Prototype ideas and solutions before you build them
Before you commit to building a production version of something make sure you prototype (as quickly as possible). This can be a clickable mockup, a paper prototype, a powerpoint deck, or even role play. The idea here is not to validate that your solution is sound, but rather to try hard to understand what is wrong with it. I guarantee you will learn something valuable and your solution will change as a result.
5. Iterate until you see the behaviours you want
Make sure that when you allow customers to use a production version of your solution that you have the ability to understand whether those initial users are behaving as expected, if not, keep improving it until you see the behaviours that you wanted.
Everyone should be doing this
When we look at what we would consider a modern software team, they are usually structured as pods, or squads and these teams are ideally autonomous and cross functional with all the right skills (design, research, product, engineering) in all the right ratios. These cross functional teams definitely make it easier to do these things, but note, even if you do not have the ideal team structure in terms of roles and ratios, these behaviours are not rocket science — if you don’t have a dedicated researcher, you can still identify the personas and talk to them — if you don’t have a full time designer, you can still create a prototype to test your ideas. Doing these things will produce great results, and soon enough you will have the buy in and support to start hiring the speciality roles and creating the modern pods.
Are there behaviours that your team engages in that I missed?
As always, if you have questions or comments let me know here or connect with me on LinkedIn.
