Principles of RevTech Solution Design

Solution Design in a Revenue Technology Environment

Over the past decade, I’ve developed a set of general principles of solution design in a revenue technology environment. By revenue technology, I mean any technology related to marketing, sales, or customer success, but particularly marketing automation and CRM systems that form the core of the revenue technology stack. By solution design, I mean the art of setting up these systems to solve a particular problem such as lead scoring, lead nurturing, or handing off leads from Marketing to Sales – the activities that fall under the widely adopted and relatively new category of revenue operations.

Some of these are generally accepted design principles, others I just sort of made up (AKA innovation and “earned practices”) based on years of experience doing technology strategy consulting for Intelligent Demand clients and with ID’s technology team across different industries, use cases and business goals — in the real world.

Apply these 16 principles to make your revenue operations more efficient and effective, make your solutions more robust and scalable, and ultimately do a better job of growing your revenue. That’s what it’s all about right?

1. Meet the organization where it is

Part of this principle is a matter of basic rules of presentation: always know your audience and adjust your presentation accordingly. But it’s not just about presentation, it’s about content and substance as well. Your solution design must be something the organization can actually implement, and something they are ready to do. The change you’re proposing needs to be something they can handle, both technically and organizationally. Understand the organization’s capabilities, level of sophistication and appetite for transformation, and design a solution that is reasonable for them to implement. Meet them where they are and then put them on a road map with a manageable pace to higher levels of sophistication and improved results.

2. KISS (Keep It Simple, Stupid!)

This basic principle is surprisingly difficult to follow in practice. You want a solution that is easy to implement and maintain and causes a minimum of potential issues in the future, so you should stick to the simplest possible solution that truly addresses the problem at hand. Resist the temptation to add in solutions to other problems you haven’t been asked to solve, or to add extra features just to make the solution seem cooler or make yourself look smarter. People will be more impressed if you improve results and/or save time and money than if you build a space shuttle to go to the corner store for a beer. It is remarkable how often smart, experienced solution designers get this one wrong. Always ask yourself and your peers if there’s an easier way to do it, and whether your solution is over-engineered. Prefer default configurations of standard tools over custom configurations and purpose-built tools whenever possible.

3. Don’t oversimplify 

The inverse of the KISS principle is also true. You need to address the entire problem in all its real complexity. Implementing a simple solution that only solves part of the problem or solves the wrong problem will not get the job done. The risk of this is particularly high when using default configurations of standard tools. If you have a hammer, every problem starts to look like a nail. Remember that every problem is unique, and make sure your solution addresses all of the core aspects of the problem at hand as well as its ramifications and downstream impacts. If necessary, phase your solution out over time – start with a simple solution that solves part of the problem, but have a plan to address the rest of the problem with refinements of the original solution over time.

4. YAGNI (You Aren’t Gonna Need It) 

This is a special case of the KISS principle – don’t build things until you actually need them. By the time you get to the imagined future where you thought you were going to need it, things will probably have changed and you will need something different. Build only what you need to solve the current problem. (This also works really well when you’re packing for a business trip, by the way.)

5. Plan ahead 

While you shouldn’t actually build things until you need them, you should think about what you might need to build in the future, and you should make your solutions maximally extensible so as to allow for future development. Don’t make choices now that will prevent you from doing what will be needed later. Use visualizations to communicate the ideal future state, get everyone aligned on the vision for the future, and make sure that your current solutions are moving toward it. Design for change and flexibility – make choices now that maximize the number of choices available to you in the future.

6. Consider costs, ramifications, and political impacts 

Learn to think beyond the purely technical aspects of solution design. It’s relatively easy to design a technically correct solution to the problem. It is often much harder to design one that will be cost-effective, have minimal negative impact, and be acceptable to relevant stakeholders. Sometimes the right thing to do is to accept a solution you believe is technically inferior because it is cheaper, or because a key decision-maker is invested in another solution that will also work, and that’s OK.

7. Learn to observe the rules before breaking them 

Your solutions don’t always need to follow “best practices” for lots of good reasons – our field is too new and innovative to have truly best practices like they have in fields like structural engineering. People have been building bridges for thousands of years. They have not been doing anything remotely like digital marketing for more than a few decades, and everything we do is somewhat innovative. However, there are generally accepted best practices for a lot of things, and you should make sure you understand what they are and why they are that way before you start doing something different. If people usually do it a certain way, there’s probably a good reason. Learn what the reason is so you can make an intelligent decision about whether it applies in this case.

8. Collaborate with both marketers and technologists 

The solution designer serves as a bridge between the worlds of revenue growth and customer experience on one side, and technology on the other. Learn to collaborate with people firmly rooted in both worlds. Make sure you’re talking to and running your ideas by stakeholders in marketing, sales and customer success who understand the business requirements of revenue growth, and also developers who understand the limitations and capabilities of technology. Maintain a balance between flexibility and rigor. 

9. Always make a choice 

When you’re having difficulty choosing between multiple options, do not simply pass the problem along to your stakeholders by presenting them with an open-ended choice — make a definitive recommendation. Remember that you’re the expert, and because of your set of experiences, you understand the nuances of both the problem and solution. If you’re having trouble with the choice, how are your stakeholders supposed to know what to do? If you cannot make a definitive choice because the decision is out of your control or not your responsibility, then make a clear recommendation and give the reasons for the recommendation.

10. Phase your designs (crawl, walk, run) 

Design in an iterative, agile way. Start with a minimally viable product (MVP), then improve upon it in phases. This is easier on the budget and makes implementation smoother, gives you the chance to prove value before over-investing, and it’s easier to sell.

Also known as “don’t try to boil the ocean.”

11. Separation of Concerns

Whenever possible, build each component of the solution separately, to solve only one part of the problem at a time. Design each component to work on its own independently of the others, and test them independently, so that each part of the solution works by itself as a little mini-solution. This is closely related to what are called the Single Responsibility Principle and the Principle of Least Knowledge – that is, each component should only be responsible for one thing, and the components should not need to know about the inner workings of other components in order to function. 

12. DRY (Don’t Repeat Yourself)

Avoid redundancy in the components of your solution. If you find yourself repeating parts of the solution inside other parts of the solution, separate them out into an independent component as discussed above. Repetition may be the foundation of adult learning, but it’s not the foundation of good solution design.

13. Murphy’s law – if it can go wrong, it will 

Also, anything can go wrong. Design for errors, and design error handling into your solution. If something goes wrong, your solution should fail gracefully and if at all possible verbosely (it should indicate that it is failing and why rather than just failing silently). Each component of the solution should assume that other components can and will fail and handle that situation appropriately. Don’t assume that the functionality of the underlying system will work in all cases. Assume the platform will fail, the network will fail, the people will fail, etc.

14. Use naming conventions 

Use a clear and consistent convention for naming things, and document it. Naming conventions help with reporting, documentation, consistency, and just generally make your work more professional and easier to maintain.

15. Document your solutions

Write down enough that someone unfamiliar with the details of the system can easily understand what you did and why, and enough that a competent user of the system can reproduce your work. Even if you are building the solution yourself, assume it will be built and maintained by someone else and document accordingly.

16. Don’t over-document

This is not rocket science. You don’t have to document every single infinitesimal detail of everything. Document enough to be clear, not so much as to be unclear. Good solutions should be clearly and simply designed so as to require minimal documentation anyway.

I hope you found these helpful! We use these guidelines at Intelligent Demand every day with our clients. 

Did I miss any important ones? Comment below!

And reach out if you or your team needs help selecting, implementing, integrating or optimizing technology, data or analytics at your company. We’re here to support your success with MarTech, AdTech, SalesTech, data, process and analytics — AKA RevOps.

More from Intelligent Demand

Eli is an old-school geek who fell in love with marketing technology. In addition to writing code and setting up advanced configurations in marketing cloud applications, Eli helps ID clients navigate the ever-shifting martech landscape. At some point, Eli will probably ask you for admin-level access to all of your systems (if he’s working on a project with you, or even if you just meet him randomly at a conference). It’s OK though, he knows better than to touch anything without permission, and with permission, he’ll make them hum like a Tesla roadster.

Leave a Comment

Your email address will not be published. Required fields are marked *