This is the third article in a 4-part series covering the challenges from idea validation to MVP creation, maintenance / new feature creation and finally Upgrading UI.
Your first customers are using your product, and the word around the water-cooler is that you have a really cool solution. But now the first new feature request comes in, the next control someone wants access to, the first enhancement, the first custom screen. Now you have to tweak your navigation system to support another page or 10. And this doesn’t stop – it never stops. Every workflow, every page, and widget you shipped now needs to be maintained with love and attention to keep your customers happy, while at the same time your team needs to focus on building the next key feature (there is always another key feature on your roadmap).
And what’s worse, success doesn’t just depend on what your specific project does or does not do… it also depends on the industry “bar.” For a long time having an effective UI wasn’t a requirement for a new enterprise app, but now it is standard for any B2B software solution or IT project. And not just any UI, but it is extremely important that every UI has theming, has internationalization, has UI access control – and the list goes on and on. As the industry changes and evolves, more things are expected of your solution beyond the domain-specific features you need to ship!
Maintenance is a war you cannot win. It feels like a war of attrition. And the current conventional approaches just don’t scale.
Hire More Engineers
This is only possible in the largest of the large companies. Hire (or reorganize existing staff into) teams of 50, 100, 250 full-stack/front-end engineers. Now half or ¾ of your team has to spend time on customer enhancement and feature requests – and only the remaining developers (and designers – which of course you must have more than one of) can focus on creating the next marque capabilities. But unless you are really growing your sales and ARR, this is a constant pipe dream – and your roadmap will likely slip away in favor of chasing customers. And don’t even ask if the changes your maintenance team is making are compatible with those of your new feature team.
Score
⬆ Many People | ⬆ Lots of Money | ⇣ Not Realistic
⬇ Removes Focus on your Roadmap | ⬇ Minimal Risk
Expand to offer Professional Services
The cash-cow of most modern large-scale enterprises. Have a professional services team that will (for an agreed-upon price with a customer) build any request. This ensures the cost spent on these enhancements is paid directly by customers, and your overhead is reduced; our core team can now focus on your main product and feature roadmap. This can be a great solution, and it brings in revenue. But for this model to work, you need to have enough customers to justify/cover the cost of all the services you sell. Furthermore, your customers must depend on your solution enough to want to pay to customize it. Plus your customers must also have the budget to keep paying for your services. So while this is more attainable than a 200 person design and dev team, it is outside of the scope of most IT organizations, startups, and product teams inside of enterprise — especially B2B companies whose primary business is not software. Not only will it likely be out of the scope of your teams, but the business model can also be radically different from your core business – how you bill, the terms of service and service level agreements, the ratio of staff expense to revenue, and on and on and on.
Score
⇡ More People | ⇣ Less Money | ⇣ Not Realistic
⬆ Keeping Focus on your Roadmap | ⇡ Somewhat Risky
Ignore your customers
Take this approach at your own peril. If you trust your roadmap so much, you can focus on your new features and enhancements and only address bugs and incomplete functions you hear from customers. Plenty of companies have tried this – they have such a captivating product/service that customers will use it no matter what, or for many IT/HR solutions it might be the only available solution so you have a captive audience. And sometimes (like for IT teams) you already have too many other new projects to develop – you only return to existing solutions if they truly break. Here you hope you can focus more only on new projects and features – and try to ignore your existing technical debt by outrunning your shortcomings with new technologies and solutions – also known as “smoke and mirrors”.
Score
⬇ Fewer People | ⬇ Minimal Money | ⬇ Highly Un-Realistic
⬆ Keeping Focus on your Roadmap | ⬆ High Risk
The key observation here is that products don’t just “stop” once you go live with a new release or come out with a new feature. These are living solutions that need care, attention, and upkeep. How do you maintain your moving train, which can’t “pull over,” while still adding a dining car, sleeping car, and 200 other types of cars?
- It isn’t enough to hire more people, you won’t have the budget
- It isn’t enough to make/sell professional services, you need a large, active and deep-pocketed customer base that is already deeply committed to your product.
- It isn’t “smart” to ignore your customers, you need to respond to their needs, but you can’t ignore your roadmap.
A solution is needed to increase the likelihood of success, decrease time to market, decrease delays, and ensure a consistent output. You need to free up your team as much as possible while keeping customers happy and moving your company forward. This is the exact moment where a change can happen, where a new type of solution can change the trajectory of your project.
But honestly, even once your product is in motion – we may just need a new way to think about our front-ends….
See Our Next Article In This Series:
