Products Are All About...

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

You believe you know what you need to build. Your customers (internal or external) are falling over their feet for your vision. All you need to do is get your MVP, your V1.0, into their hands. And once you do, you can pour fuel on the fire and take off. But how do you do this? How can you get there as quickly as possible, with as few resources (time, money, people) as possible? We all know, building a product takes a lot of work – so the more of the burden that you can take off your team’s shoulders the better.

The current approaches (at least for front-end creation) presented below just simply don’t cut it — You need a new type of solution that can change the trajectory of your project and maximize your chances of success.

You could build your entire front-end by hand

This is how most projects are built. Use a framework (React, Angular, Vue), choose a handful of libraries (D3, Highcharts, Components), and then hire a team of UI/UX designers to figure out the optimal solution. Then hire a team of engineers to build it out. You get control over architectural/design decisions, and everything can be pixel perfect.

However, this takes time – and we mean a LOT of time. Everything is a decision that must be made and likely discussed. Architectures are often custom-made, making them hard to understand and maintain by consultants and contractors. And your skilled team (and we mean a full develop/test/deploy team) must hand design and code every configuration screen, every navigation element, every detail – even the ones that aren’t going to move the needle. And of course, there is a high amount of risk because it will take months to know if you have even built the right thing.

SCORE

⬆More People | ⬆ More Time  |   ⬆ More Money  |  ⬆ More Control
⬆More Risk |  ⇡ Some Technical Debt |  ⬇ More Resources to  “Move the Needle”

You could use templates

Every new project is tempted to go online and download a “template” for a product. Usually, this will come with a pre-canned dashboard and navigation system – maybe another page or two. And these template’s cost is absolutely minimal, and the screenshots posted look super slick. Certain gaps can be covered without needing specialized engineers or designers.

But now, your team needs to convert these “stubs” into an actual product. Your engineers need to slog through all this code (which likely isn’t well organized, documented, or written) to ensure every button does the right thing and every link goes to the right place. Every widget on a dashboard and every user input now needs to be customized – and I don’t just mean changing a name. Widgets need to be completely reworked to integrate with your data, your interactions, your product. And what if this “template” doesn’t support a feature you need (e.g., internationalization, theming, UI access control). In that case, your team needs to go through the entire project and refactor all the code you got as a “template,” re-writing large chunks. And why did those screenshots look so “slick?” It is because the demos were overly-simplified – they often have tons of pictures, people’s faces, and visually pleasing UI elements that have no relationship to an enterprise product, IT solution or B2B software. And once you remove that useless eye-candy, you are left with the hollowed-out skeleton – and saddled with the technical debt of someone else’s architecture and design decisions. But you didn’t start from scratch, and you got out the door faster. But have you ever wondered why most startups, companies and IT departments don’t use templates? That should say something…

SCORE

⬆ More People |  ⇡ More  Time  |    ⇡ More  Money  |   ⬇ Limited  Control
⇡ Some  Risk |  ⬆ More Technical Debt |   ⇣ Some Resources to “Move the Needle”

You know your customers’ pain points. You have a vision – a solution. It isn’t some generic vitamin — you know you have a kick-butt pain killer. Now you got funding or approval for your project. You are ready to go. The next step is to validate your solution, iterate quickly, fail fast, then iterate more. You don’t have time to spare, because you know your competition might be just right around the corner. 

The conventional approaches presented below just simply don’t cut it.  You need a new type of solution that can change the trajectory of your project and maximize your chances of success (while reducing risk).

You could take an ethnographic approach

Go interview tons of potential customers, but starting down this path is slow and hard. Without something tangible to show them, words can be misinterpreted – brilliant ideas become vague and unclear – and you can get led in the wrong direction through a simple misunderstanding, especially if your idea is really new and the users have no reference for evaluating it. 

SCORE:

⬇ Low Fidelity | ⬆ Good Feedback  | ⬇ Minimal Validation
⬆ Much Time  |  ⬇ Save Money | ⇣ Minimal Risk

You could take a design-centric approach

Go hire a designer (full time or contractor) to go make mockups (pictures). You can even use some amazing tools like InVision or Figma to make those mockup pictures be clickable to “simulate” a real product. But mockups take time.  Weeks of time. Every iteration is another week or more before the next set of designs. And while InVision and Figma are great for bridging the gap between design and engineering, let’s be honest – clickable pictures are still a far cry from having a user “interact” with a real product with real data. Not every interaction is mocked up, the data isn’t real, and the “mockups” don’t feel like (or provide feedback like) real software does.

SCORE:

⇡ Minimal Fidelity | ⇡ Minimal Feedback  | ⇡ Minimal Validation
⇡ Some Time |  ⇡ Some Money   | ⇣ Minimal Risk

You could take the build-it-first approach – Like so many startups, IT departments, and new product development teams at large companies – you could just “build it first.” And it is true, what you get on the other end is as high fidelity as possible – but it takes time. And I don’t just mean weeks… Building a functional product takes months. It isn’t just the front-end; you need the APIs, the databases, the analytics, the data. And if you find out 4, 8 or 12 months late that you built the wrong thing (or even the right thing with a totally wrong UI)… well then. You better hope your competition hasn’t figured out the right answer.

SCORE:

⬆ High Fidelity | ⬇ Delayed Feedback  | ⬆ On-Point Validation
⬆ Much Time   |  ⬆ Much Money   |  ⬆ High Risk