It happened for the thousandth time & I have to do something to stop this. 

A client came to me today who’s trying to disrupt a billion-dollar industry, but made the same three mistakes that I see new entrepreneurs and intrapreneurs, specifically non-technical ones, making over and over.

In this case, they had worked hard to validate the system but missed a key ingredient (mistake #1). Then the CEO told me the same thing I’ve heard probably hundreds of times at this point in my career (mistake #2):

I asked more questions about how the development team is being managed and learned that the CEO with no technical experience was driving development (mistake #3).

After the conversation, all I could think was:
“Someone probably just wasted a lot of money.”

Today I am going to tell you how not to throw away all your money building a new SaaS or application.

Let’s dig in ⛏️

Also, check out this week’s free resources here and this is a particularly long email. If it doesn’t load, you can see the whole thing here.

Mistake #1: Not Validating Key Metrics

The day I realized this article needed to be written I was working with a client who is trying to launch an ad-driven lead-aggregation system (a system that generates leads and sells access to these leads). The startup was fairly far along:

• Development-wise, the system was 75% complete

• Marketing materials, including infomercials, completed

• A team in place

• They were in the process of raising capital

• Buyers were calling to ask when the product would be complete

Most importantly, they felt they had validated the idea with buyers due to the high level of interest in the system. They had spoken to many customers about the new offering, presented the idea at meetings, and were confident that customers would buy. In other words, they were doing a great job on some aspects of validation.

So what’s the problem?

The problem is that on a lead generation system, the application can be the most beautiful, most robust, most impressive system on the internet, but if their assumption on the cost per lead for their target channels doesn’t hold up, the entire business doesn’t work as it was initially conceived.

In other words, OF COURSE people loved the system because they were promising a cost per lead that is likely lower than customers can get elsewhere. When you offer to beat market rates, customers are going to love you. One of the first steps I take in reviewing a forecast is to identify key assumptions, so when I looked over their financials, I quickly ran the math on what their cost per sales qualified lead should be in order to make the business work and asked if they had validated it, the answer was no. So I helped them quickly build a landing page and run ads to the page to see what the cost would be. As of the time of writing, this test was still in progress. If the cost per lead is within their range, then the system will launch as planned. If not, either they will have to change the pricing, make bigger changes to the business, or abandon it completely. Since it’s early on, it’s likely one of the first two options, but that’s not always the case.

The Key Takeaway

So figure out your key metrics first from your forecast, validate that your assumptions on those metrics are true to ensure you’re building a system that works financially, THEN design it, THEN develop it, THEN keep iterating and improving. If you don’t do this, then you’re going to potentially waste a ton of money for something that could potentially never make a penny.

Over my career helping companies like this I have seen it happen many times. People come to us with what they think is a conversion, design, or development issue only for us to show them that it’s a key assumption in their business model that does not hold up and the business was dead before it ever started. Not that it can’t be revived sometimes, but it’s rare because most of the time when they get to this point they’ve blown through most or all of their budget and there isn’t time or money left to make the big changes that need to happen to fix the business.

Mistake #2: Starting At The Wrong Step

Think about it like this: Developers excel at making systems work, while designers excel at making systems usable, and usability comes before coding. So who goes first in building an application?

If you chose design, you’re right.

In other words, you design the application with a designer's help first, then check it with customers, make changes, check it again, and repeat until you have a system that will meet your and your customers' needs. Then, you start working on development.

If you’re not familiar with UX design systems like Figma, let me explain. You can design the look and feel of the system in this tool - it looks almost exactly the way it’s going to look as a web application, and you can click through the system. You, your team, and your potential customers can view the areas of the system and use different tools in the application BEFORE you spend a penny developing anything. This way you can iterate on the design, and there will be substantial changes, THEN the developer can work on the time-intensive and costly part of making the system work after you’ve nailed down exactly how it should look and work.

Where to start and who to hire first

If you’re not using an agency or pre-built team, start by hiring a DESIGNER, specifically a Product or UX Designer (not a graphic designer). In some companies these roles are synonymous, but in most places, a Product Designer is more senior than a UX Designer.

If you’re not familiar with the different kinds of designers, the UX or Product Designer is a technical designer who designs the layouts of pages and views along with the different interactions and states of those views. This is a person who has at least basic coding skills, is knowledgeable about and has studied how humans interact with software systems, and preferably has at least five years of experience building systems similar to what you are building. This person can help you take your project specifications from ideas to wireframes to prototypes and ensure that your product meets user needs and business goals at each step.

UX/Product Designers Are Skilled Roles

The UX Designer will not only start working on a beautiful design that meets your specifications, but a good designer will also insist on meeting with end users to ensure nothing is missing and that the system works for them. They will also bring up new ideas for product improvements. The designer will build out user workflows and journeys in flow charts to ensure there are no extraneous steps and that at each step, the user is getting what they need and nothing more.

Next, they will assist or lead in conducting user research to ensure the process meets the user’s needs properly, then they will build out wireframes and prototypes of the designs. Finally, they will work to iterate on these designs to improve user experience and value.

The ROI Of User Experience

The investment in proper design pays dividends through reduced development costs and higher user satisfaction. According to Forrester, it’s a ratio of $9 return for every $1 spent on design, which sounds about right from my experience.

The Process Of Product Development

The process of product development (including design) is iterative, not linear. You and your team are going to make changes as you go along, very often these are substantial changes. Making changes in design are quick, relatively inexpensive, and can often be done in a few minutes and upwards of a day or two. Whereas the same changes take days, weeks, and sometimes months to complete in development. Even after you complete initial iterations of the design, you are going to want to see different versions and have new ideas and those too take time, but a lot less time in design than in development.

Doing these changes in development instead of design impacts:

• Speed to market

• Cost

• Customer Satisfaction

Not only is it faster, but this approach involves a specialist who focuses on solving customer issues from a design perspective rather than a developer who is focused on the system's functionality.

The goal is to get the design working well and solve the user’s problems as best as possible BEFORE a developer touches the system.

The Critical Caveat

You need a developer to review the scope of work and the designer's work as they design the system to ensure they don’t miss anything, which they often do. The developer can also help ensure that designs are put together in a way that is less expensive to develop. Simple ideas from a designer can be very time-intensive or expensive on the development side.

A good example of this is the time a contract designer I was working with put a chatbot design into an application and added some AI capabilities - easy to design, but very costly to develop. While it was a great idea, which designers are full of, it was completely impractical within the budget or timeline and was completely out of scope for the project. The developer saw it and immediately asked “How do you propose we build that?” To which the designer opened the file and started removing the section. This is a more extreme example, but it happens all the time.

The Design First Approach Gets You…

• Moving faster

• Solving more problems

• To market faster

• Saving a LOT of time and money making changes

• Happier customers

In other words, higher sales and lower churn.

When Developers Try To Be Designers

If a developer tells you that they can do the job of the designer, think about this: If you spend all your time coding, you can’t spend all your time designing or, if you spend all your time managing a business you can’t spend all your time doing heart surgery. You can be a great businessperson or a great heart surgeon, but you can’t be both. It’s just the way the world works. So if you have a great developer, I guarantee they are not a great designer.

In my entire career, I’ve met one person who studied and practiced UX design for more than a decade, then went to school for computer science and spent the next decade as a front-end developer. He was pretty good at both. But even he would tell you that had he spent all of his time on one or the other, he would have been better at that, and the more time he spent in the developer world, the rustier his design skills became.

Examples of Developer vs Designer Driven UX

Experience Care Document Management System

This is an example for Experience Care, the company we sold to WellSky last year. When I first took over the business, our product had been in a developer-driven design system for almost 30 years.

This was their documents management system when I got there:

Like I said, i started off as a UX Designer, so one of the first things I did was start building a more robust product team. After the new design team finished it up, it looked like this:

HeyRamp.com Team Performance System

I know what you’re thinking, it’s not always as bad as the example above, and that is true. So let’s take a look at an example where a very capable developer (and business partner) using modern frameworks and themes was working on an application vs once a UX Designer took it over.

Below is the work that the developer did with only design guidance from me (a senior UX designer). Other than reviews and meetings, there were no deliverables. The work was usable, but some items were difficult to use or could have been improved. Since this company competes against companies with great user experience, it needed at least a part-time professional UX designer to review and build new designs for the developer.

Now here is what the system looked like after the UX designer was finished…

If you want to full breakdown of what was done on HeyRamp, here’s my side-by-side breakdown.

Does your application need a review? Are your customers upset about usability? Are you losing customers and aren’t sure how to fix the system? We can help with a 100% FREE audit of the system.

Ok, Got It. No Developers To Start.
What’s My First Step?

Start by scoping your system and building a forecast. You’ll need this Scope of Work (SOW) to build your financial forecast, but also so you can plan out the different phases and releases for the product. I am breezing past these two steps since it’s not what this email is about, but these both take a lot of work and are critically important.

Planning it out means WRITING IT DOWN. To do that, you’ll be spending some time writing out every page, every feature, and every system in the entire application. This is important because having this fully written document helps your team estimate the cost and timeline to get you to MVP. Just like my note on validation, this isn’t a writeup about how to scope a project, so I’m not going deep on this, just telling you that it needs to be clearly written out and the clearer and more concise it is, the less it’s going to cost you in the long-run.

Financials First

You’ve got the system scoped, but don’t start engaging the designer yet. You’ll need to build out a financial forecast before starting on any design or development. Only once that’s been done and you are sure the system will make money and you know how much capital to raise will you be ready to actually start designing or developing anything. Only after these items are done can you move to actually developing anything.

You may also need some designs to obtain funding or demonstrate key ideas, but once again, you need the designer, not the developer, for that.

Mistake #3: Team Setup & Roles

Great products don’t just need a designer and a developer; they need a team consisting of at least a Product Owner, Product or UX Designer, and Developer, and very often a Quality Assurance (QA) developer or engineer. Other development specialists include a front-end developer and, nowadays, an AI/ML Specialist.

If you’re not a technical founder and don’t have one, let me introduce you to the lead roles on your software development team:

A Product Owner

A person who understands what needs to be built, has vision for the future of the industry and system, can and does regularly interact with users to ensure what is being built meets their ever-changing needs, and has the technical skills and training to write stories (informal, natural language descriptions of one or more features of a software system) for the product development team.

Very often for startups either inside or outside of an existing company, the Product Owner is the manager or entrepreneur running the startup. But, this is a job that takes a lot of time. It’s not a 5 hour per week job, especially if the product is in development, and this is where a lot of new tech startup entrepreneurs fail. They think they can manage product development as well as be a CEO mostly because they don’t understand what a Product Owner does and the amount of work that goes into it.

A Product Designer or UX Designer

We covered this role already, so here’s a recap. This role can take the vision of the Product Owner and customers or users and turn it into an intuitive system that is as easy as possible and in many cases a pleasure to use. This is a skilled role that can take complex information and make it simple and visually pleasing for people.

Additionally, a UX or Product Designer may conduct user research, build user personas and journeys, wireframe the product, run usability testing, prototype the system, and more. In larger teams, these roles are often divided into other subspecialties.

A Developer (often more than one)

A person who knows how to code in the appropriate language for the system being built within the ecosystem of the organization. This person understands how to move data, work with databases, and represent the UX designer’s designs in code. It’s important to know that very often the Development role is broken into many subspecialties including front-end (taking the design to code) and back-end (making those coded designs operate as planned and expected).

There are many, many other kinds of developers, such as AI or Machine Learning developers, database specialists, and specialists in individual languages.

A Quality Assurance (QA) Engineer

QA engineers ensure software quality through rigorous testing and by building automated test scripts for continuous integration and deployment. This means that when a new feature is built, they make sure that all the old features didn’t break when this new one was created and they build automated tests to make sure that when the next feature is built it doesn’t break this feature. Automation is extremely important as a system scales because at a certain point in complexity it takes more time to manually test and debug than it does to build new features.

So often I’ve been told “I already have a developer, why do I need a QA? Why can’t the dev just do this?” Here’s why; if the developer saw the issue they would have fixed it the first time. It’s just the nature of people that they are blind to their own mistakes. I have worked with amazing developers who have made silly mistakes, I’ve done it myself. If you don’t have another set of eyes on the code there are always going to be problems that slip through.

Other Important Roles and Subspecialties:

Think about developers like doctors. You don’t want your cardiologist doing brain surgery, it’s a terrible idea. Your heart will keep beating, but it doesn’t help if you’re brain-dead. The same thing applies here.

Front-End Developers: specialize in converting mockups into functional and responsive web interfaces.

DevOps Engineers: Manage deployment and infrastructure

AI/ML Specialists: Implement artificial intelligence solutions, which is especially relevant these days.

Specialist Developers, Sysadmins, Security Specialists, and More: Handle multiple aspects of the application such as complex data analytics, cloud infrastructure solutions, and much more.

You Don’t Need Everyone Right Out The Gate

If you’re starting something new, you don’t need everyone right away, but you do need to plan out who you’ll need and when. After validation start with design for customer-facing applications, NOT with development, and you need to hire a team that supports the key aspects of the system as they are needed.

Most importantly, for any business system, you need to start with a well-validated problem.

Need to hire, set up, and manage a product development team? Get help here.

Let’s Recap:

Whether you’re building an application, SaaS system, marketplace, or anything else that requires web application/software development for a big business or a startup, here’s your process (not including raising capital):

1. Plan and scope your system so you can build out accurate financial forecasts.

2. Validate the system, including every key metric.

3. Design the system with a UX or Product Designer and iterate heavily in this phase.

4. Once you have thoroughly designed the system, THEN have the developers start.

5. Once you launch the product and start making money, continue iterating and building new features using the same process as above.

Whether you’re building a new product or continuing to grow an existing one, here’s your high-level process: Validate, Iterate, Design, Iterate, Develop, Iterate, Release, Repeat. If you want to learn more about how the process actually goes from a more technical perspective, take a look at the Atlassian Agile Guide and the Wikipedia article on CI/CD.

Friends Don’t Let Friends Throw Their Money Away

Tell people about this, and follow it yourself so I can stop telling people they need to start over.

Finally, if you want someone to hold your hand through this whole process, that’s what we do at JHMG. Click here to get help with your SaaS business or offering.

Now that you know the basics, please share this with anyone who is thinking about building an application or SaaS business. It can save them a ton of time and money, tears, lost hair, lost relationships, and more.

Free Resources

Signature Sync - Managing everyone’s signature across an organization is a huge pain. We got a different system a while back that is similar to this and it has helped a lot. Here’s my walkthrough of how we use that system. So far, this one looks even better, at least from a design perspective.

SuperOkay - I bought this deal years ago and have used it for my coaching clients for that time. At first, they were slow to update the system, but they have moved faster and faster and these days are running a good application. It’s a much more mature product now and for the price it’s a good deal.

AudioHero—As you probably know, I make a lot of videos. However, I don’t have to pay for all my sound effects because I use a tool like this one. If you’re doing video and sound work, this is worth checking out.

We’ve been working with a small apparel business for a while now and their results have been striking. With the help of JHMG, they have grown into the fastest growing brand in the niche!

I sincerely hope this is helpful!
Jason Long
CEO
JHMG
Find me on my LinkedIn