Toddlers can be really cute. And they can be really destructive.
But did you know that toddlers can help you decide what software should do?
Let us explain.
Several of our team members here at Worthwhile have toddlers at home, so we know all the great things about having toddlers as part of a family. We also know that toddlers must be watched like a hawk, because we know the toddler rule.
What is the toddler rule?
Just because you can do something doesn’t mean you should do something.
If you have toddlers, or if you have been around toddlers, or if you have ever watched a funny toddler video online, you know how this works.
A toddler can climb the bookshelf, so he does climb the bookshelf. And then knocks 37 books to the floor. And then falls and lands on the books.
A toddler can ride the dog, so she does ride the dog. Until the dog runs under a table and knocks the toddler off.
A toddler can go in the room while daddy is doing a TV interview, so she does go in. And then little brother does too. And then this happens. And then it goes viral.
Most parents of toddlers who saw that video probably thought, “Yeah, I could see that happening in this house too.”
Toddlers don’t have the experience or the discernment to decide something is not a good idea. The people in their day-to-day lives—parents, babysitters, teachers, relatives, siblings, and more—help them develop. By learning these things, they have a chance of going through life (relatively) unscathed so they can become productive members of society.
So what does this have to do with software development?
You want any software system your business uses to be a productive member of your technology stack. But that doesn’t just happen. You have to work together with other people in the day-to-day life of your company to develop a software strategy based on what that particular piece of software should do as part of your business.
And to do that, you’re going to have to say no to a lot of things that a particular piece of software could do.
The toddler rule of software development requires your business to make hard choices about the features and functionality you include in a piece of software.
This principle is vital to the successful launch and life of any software system. So want to break down the key things it teaches us, so we can stay off the bookshelf and keep from bonking our heads on the table.
What are features and functionality?
Whenever we begin a conversation with a client about building software, we start thinking about a few basic categories:
* Database—What data needs to be stored, and in what form
* Users—What different user types are there, what will they do in the system, and what permissions will they have
* Architecture—What back-end models and front-end views need to be in place for users to do what they need to do
* Features and Functionality—How will the user do what they need to do
Generally, business leaders don’t have a lot of decisions to make on the first three items, because they are defined by the user flow. The leaders know what users need to do, and they’re ready to approve the architecture and database needs to make that happen.
(Of course, choosing what users and user flows will use a software system is a toddler-rule decision too. More on that later…)
But features and functionality are more a matter of taste. Features are user-facing polish. Functionality is the back-end programming that makes features possible. They add polish to a system, and they can add pretty significantly to timetable and cost.
Examples of Features
* Online chat
* Map or social media plug-in
* Data visualizations (graphs, charts, progress bars, etc.)
Examples of Functionality
* Form or data validation
* Search filtering
* CSV or PDF export
Features and functionality offer a world of possibilities for your business application software. That means you have a world of possibilities—and also the possibility of adding days and weeks and months to your timeline because you just can’t say no.
So you’re going to have to say no. Businesses have limited budgets and limited time to build and implement software applications. Choices must be made.
Just because you can include something doesn’t mean you should include something.
So how do you choose?
How to Decide about Features and Functionality
Most of the time, a company building a piece of custom software, or picking off a menu of options for off-the-shelf software, puts together a pretty large wish list. That’s fine, but you can’t take the Christmas list approach if you are trying to implement business application software strategically. You need to discern which features and pieces of functionality should actually make it past the toddler rule and into your system.
Here are four key questions to ask:
Is it essential?
The first question is whether the software application will work without the feature or functionality. For example, if you build a system with users, it is essential to have password recovery functionality.
This is a question your IT team or software development partner should be able to easy answer. If it is essential to a properly operating system, include it. If not, move to the next question.
Is it valuable?
After you include the essential features and functionality, look for things that make the application more valuable to its intended users. Example: If functionality like validation will prevent repeated errors before they even happen and makes everyone’s job easier in the long run, it is valuable.
Maintain a high bar for value, and measure it against the development cost of including the feature or functionality. In most cases, you’ll identify a handful of valuable features to keep on your list as you move to the next question. Anything else should go onto a long-term wish list that can be considered once your software application is launched and stable.
One warning before you deem a feature or piece of functionality as valuable: Don’t guess what your end users will think. Ask them what features would be valuable. You can do this by surveys or interviews before you begin your software project, through a testable prototype during development, or after you launch the initial version of your software. Guessing about what will create perceived value is a good way to be wrong, and being wrong delays your timeline and costs you money. So look for ways to get real answers about value, and wait to include features and functionality until you’re actually sure they’re going to be valuable.
Is it unique?
If your customers and/or prospects interact with the software you’re building, then it is important to have unique features and functionality. These will distinguish your business from your competitors, and they can also build consumer loyalty because of the additional value they provide.
These unique features and functionality can be what makes your software special and distinct. They can also drive up your price and timeline significantly. So measure the uniqueness against the ROI of each feature. And as we just mentioned, if you’re not sure, wait until you are. It’s better to launch new features as you go than to try to bite off more than you can chew and spend too much time and money in the process.
Can it wait?
Even if a feature or bit of functionality is unique and valuable, it still may not merit a place in the first version of your software. If it can wait, you should seriously consider phasing this out.
This is a key principle of phased software development. You build the minimum viable product (MVP), and then you iterate and add as you go forward.
This works with features, and you can also apply this principle to user groups. You launch a business software application to reach one or two kinds of users, and then add support for additional users as you go.
It’s like making a gourmet meal one step at a time, instead of all at once. Working in phases helps you get things right, and to complete what you’re working on more efficiently. This puts software to work in your business sooner, and allows you to start earning ROI sooner. Those benefits are worth the wait for specific features, functionality, or groups of users.
* Is it essential? If so, include it.
* Is it valuable and unique? If so, consider it.
* Can it wait? If so, phase it.
Toddlers eventually grow up. They learn things like delayed gratification and cause-and-effect. They learn that they shouldn’t do everything they could do.
Your business needs to grow up too. And part of growing up is living by the toddler rule and making your decisions about business applications based on what a system should do, not what it could do.
When you make these hard choices, you can avoid a lot of tears and crying and tantrums, and you can focus on growing instead.