I come from an interesting business background. It’s like a strange distant land where the rules of gravity are turned upside down and the most common business practices are thrown to the side.
It’s an odd place there.
It’s called “Internet Marketing” or the “Make Money Online” space.
In Internet Marketing, long term vision is sacrificed for short term profits. Where products are not built in an agile way with user feedback, but thrown together with a bunch of feature requests by a few outsourced developers.
No Brands. No Mission statements. No culture established.
And certainly, a strange aversion to building products based on user needs. Once it’s done, it’s simply time to move onto the next one.
So when we moved into SaaS, we had to make a complete shift in the mental energy around the product.
We followed the Agile Methodology.
It wasn’t an easy lesson to learn lol. We spent a lot of time learning about simplicity and MVPs (you can read that part of the journey here).
But, once we did… it was much easier to listen to users and start building what people actually need.
The biggest questions then become apparent here.
Every user has a request. Every business a unique scenario.
So how do you start to handle the overwhelming requests into your software as you start to grow and sell your product? What actually makes the “agile” sprints to new development.
This is extremely tough for any product based business.
But, it’s got to be done with the Art of Prioritization.
Here at Demio, we created an entire “Backlog Backlog” board, if you can believe it haha. It’s a Trello board that contains all our upcoming roadmap items for each part of our Application including our own ideas for future development (Internal Requests) and a column for User Specific Feature requests.
We have 4 major parts of our app (so a column for each one), integration requests, enterprise requests, architecture ideas, system ideas (internal business systems), and then “Completed Ideas.”
The key reasoning behind this is to keep our day-to-day Trello boards relatively clean and ordered so we can move into sprints without a lot of confusion or overwhelm.
Each month we’ll bring in the items for that month into the unique board backlogs based on priority.
Then weekly, we move over the items for that bi-weekly or weekly sprint milestone.
For our customer feature requests, we add a new ticket on each request into Trello and add the lead name/email OR a link to the intercom ticket (we use intercom for leads and our customer support).
Note: this is a great way to keep continual feedback with customers. As you add in those features, reach out to the users and let them know that you have added the feature request. Even old tickets, past users, or leads love the fact that they know you are listening to them. You’ll see re-activations/new sales just from this alone!
Ok, so now that you have the system in place it’s time to make the decisions.
And this is where it gets HARD.
Every feature is important, but the key item to think about is the “number of users” this affects. The other key element to think about is where you are in your journey. If sales are critical in the early days, finding key developments that can add sales (sexy requested features or features that solve major problems) are essential.
You may also find some major holes in the project that need to be fixed up. Anything functional / stability driven that affects large groups of users needs to be handled first.
Then, anything that can affect scale.
Then any new features that can help add revenue. Then any feature requests for larger user percentages. Then “nice to have” features, if it actually improves the product.
The key thing here is sometimes you have to say, NO.
You can’t add everything and you certainly don’t want too early on.
It’s got to be a weighted decision to help the largest number of users in the quickest feedback and scale the sale to those people.
Not everyone is going to be the right fit (especially early on). What you want is to find the right customers, dial it in for them, and then scale it out.
Then you can go wider. But, even then… just adding features doesn’t always make you better.
In fact, there’s times when it hurts you. It can take away the ease of use or understanding of your app, which may be why your original users even came there.
So be dedicated to sticking to your guns. It hurts to turn away users and sales, but for the longevity of the mission you’ve got to stick to those priorities.
Having your company mission pillars written is always a good way to judge those items in line.
It’s tough, but no one said it would be easy 😉
Now go get out there and start learning what your users want!