Contents
Part 1Why Do It, What It Is
Part 2Market Validation - Need
Part 3Market Validation - Environment
Part 4Product Validation
Part 5Technical proof-of-concept
Wrap UpFollow the Path
Your Vision. Comes to Life.
Today I'll provide a thorough coverage of the goals of a proof of concept in SaaS development. Major sections covered are:
Read all the way through or jump to sections of interest in the table of contents below.
ContentsPart 1Why Do It, What It IsPart 2Market Validation - NeedPart 3Market Validation - EnvironmentPart 4Product ValidationPart 5Technical proof-of-conceptWrap UpFollow the Path
PART 1
The proof of concept is an often skipped step, but the most important at reducing risk. We'll discuss:
I’d talk to customers and validate my assumptions before writing a single line of code – Common response of 80+ failed startup interviews
I’m not giving real estate advice, but I’m pretty comfortable with the idea that building a skyscraper in a sparsely populated area is a fool’s errand. It’s obvious, right?
So why isn’t it equally obvious that building a SaaS product, without first understanding if you can get tenants, is also a fool’s errand? If I’m to speculate, it is because there have been many examples of people who skipped the market analysis step and still came out on top.
They did the equivalent of deciding to build a skyscraper in the city. They understood the dynamics at play and came down on the right side. They didn’t need to understand their market any better than they already did - or maybe it just looked that way?
How many times have you seen something that appeared simple, but after deep study into the details, you find that there was so much more at play than you originally understood? Although it appeared that someone was successful without market research, perhaps it was anything but simple and there was much more done than it appears, or they confessed to?
For you, and particularly with the now very crowded marketplace of SaaS products, it is critical - nay imperative - that you understand if the market needs your product before you build it. Even the “obvious” need is a conceptual view that should be eschewed in favor of testing if a need is present, and in what way and manner. That leads me to the proof of concept.
So, what does a proof of concept mean when building a SaaS business? It is a way to validate assumptions about the market, your product and the technology. This is the start of your journey towards finding product/market fit.
As the words imply, you are looking for indications, some nuggets of proof, albeit not a guarantee, that your product concept will satisfy needs for a sufficiently large audience who would be desiring to use your product to achieve some desired need or want.
It is used to test out ideas and assumptions without having to invest the kind of time and money required to build a software solution and attempt to sell it, often resulting in a product nobody wants.
Imagine you bring a product to market, and it fails. Your analysis of what went wrong is similar to what you’re doing with a proof of concept. With the proof of concept you find out what’s wrong with your idea, without the expense, time and negative energy resulting from a failed attempt in going to market.
You also find out what is right about it, but at this stage, you are at least as interested, if not more, about what’s wrong with your ideas - what the market isn’t interested in.
The proof of concept is the start of the journey of testing your idea. With each step along the way, assuming you keep running tests and responding appropriately to lessons learned, you will reduce risk. In the early steps, you make the most substantial impact on risk reduction and over time, your product becomes less risky in terms of market fit, all other things remaining equal.
Of course, all other things don’t remain equal, so for the life of your product, you should constantly be reevaluating market fit, assessing the competition, finding out what other alternatives can be used - all the things you will do in the proof of concept - but I’m getting ahead of myself!
Just a quick note, to establish a firm grounding of where I’m going with this. While sometimes the proof of concept has a significant focus on building out an experimental portion of software (I’ll cover that later), your highest value often comes from the business analysis and its resulting risk reduction.
Other articles spend considerable time discussing the difference between proof of concept and MVP, or the difference between proof of concept and prototype. If I do my job in this article, it will be very clear what a proof of concept is. You’ll be able to clearly see the differences, as they are very different things.
In my estimation, the confusion comes from other article authors blurring the differences because of being too fuzzy on what to do in a proof of concept, its goals and major features. Often, articles on proof of concept hardly discuss what you are even trying to achieve!
Simply put, in the prototyping and MVP stages, you can focus more on the product, desired product features, user experience, and many like concerns. That is not at all the focus of the proof of concept as you’ll see soon.
When technical concerns are part of the proof of concept, it is generally to gain knowledge of whether some risky or technically difficult part of the application is technically possible. Again, more on that later.
PART 2
Are there people desperate for the solution your would-be product offers them? Are there:
I respect the market over my friends, my family, the people I respect, and even myself. – GaryVee
As a parent, it was so clear to me when our infant son or daughter needed something. The cry was a clear and present sign of an (in their mind) urgent need. As a loving parent, it was a sudden call to action to address that need.
If only it were so clear with customers and prospects. Imagine if it were so easy to have customers screaming for what you have to offer!
Well, sometimes it may be just that easy. There have been SaaS products born from discourse on social media. There’s a product that was developed from conversations at the local pub. Complaints from people discussed in a forum can sometimes be an indicator for product need. It can be one of the tests you employ in starting your journey of understanding a market’s needs.
The tests you employ to measure market need must be valid tests of actual need. Tests along the lines of, “Do you think this is a cool product idea?” couldn’t be more useless. Rather, you must assess if not having your product, a business may not stay in business or significantly struggle. Does your product impact a significant revenue problem, in the case of business-to-business (B2B) product offerings. For business-to-consumer (B2C) product offerings, you would be looking for a way to save significant time or money through your product, or provide a convenience.
Instead of a customer saying “I need some new accounting software” they will say something like “I can’t ever get a handle on my receivables.” – ExchangeDefender
An aspirational need, like a desire to be really successful, an entertainment need, or a need to achieve social status are much more difficult needs to sell than a need that is critical to survival. A product without a significant need, or one where the potential customer doesn’t even realize such products exist, is going to be really difficult to sell.
Aspirational brand strategy positions a product or service through image, appealing to what they want to be. – What’s with All the Hype – a Look at Aspirational Marketing
In the business world, a product that allows a business to create a prettier invoice might be an example of a need that a business owner may never think of, and it just isn’t that important if it does come to mind.
Ideally, your product is that obvious need that just can’t wait. When you’re in a car accident, you have a broken bone, and you’re bleeding, an ambulance service is obvious and critical to you at the moment. Some B2B SaaS products that fall into this category:
As useful as it is to think about having a product with an obvious and critical need, the jobs-to-be-done framework is even more compelling and useful.
Jobs-to-be-done offers a different approach to assessing market need by thinking about the problems a customer has while completing a job. The classic phraseology is to say that customers “hire” products or services to do a job. This means that a customer may employ your solution, or they may employ a manual or offline solution or employ a creative workaround.
If you sell shoelaces, then the job-to-be-done for your customer is holding their shoes on. They employ a shoelace to complete that job. That customer may choose to employ velcro, a buckle and strap, some kind of clip or toggle or a redesigned shoe that doesn’t require anything to hold it on.
The job may be redefined more expansively to consider that the job being done by the customer is to protect their feet from pointy objects, or to provide a fashion statement or complement to that day’s dress. As a company, you may want to eventually fulfill your customer’s complete job-to-be-done, such as making the shoe in this example.
That may not make as much sense for a shoelace manufacturer who has no competence in shoe production or desire to compete in that market, but in the SaaS world, the ability to expand thinking about the problem domain covered by your product is easier. The barrier to entry is often lower with SaaS products, so you are less likely to have the issue that the shoelace manufacturer has.
Examining the steps of a job reveals the work being done. It is important to break down the work being done into its constituent pieces so that you can fully appreciate and understand its components. Only through that can you effectively address the customer’s job-to-be-done and thereby create a product that is truly useful and has the potential for being “hired” in place of another employed solution.
Using process mapping techniques is often how one breaks down the job being done. Especially for a complex job, it can be tedious to map out every step and every conditional step and every exception that may occur along the way, but in doing so, you reveal the places where your solution can truly be valuable.
With process mapping, you can easily gain an overview of how processes are carried out, how they can be improved or constrained, and how many steps are necessary to drive the process to its endpoint. – pipefy
Whatever job you focus on, the job definition should be static. The job being done doesn’t change with time, but solutions to the work of the job can vary over time. The job of protecting feet doesn’t change although there are many solutions.
Note that a customer previously employing another solution, “firing” that product or service and “hiring” yours, may at some point likewise displace your product, hiring another solution to get the job done. That’s why the work you do here, in the proof of concept, continues throughout the life of your product.
Considering the various ways in which a customer gets the job done should be regularly revisited for the life of the product in the interest of recognizing alternatives that may be hired in place of your solution. In that way, you may look for ways in which you can either alter your product, or some externality of its use, such that you may retain the customer.
You must become expert at seeing how people use your product, what jobs they are accomplishing, why they would want to employ your product to do that job versus some other competing solution, and ideally, ways in which to lock them into your solution by creating so much value that arguments for the use of alternatives seem untenable.
Ultimately, using the jobs-to-be-done theory for discovery, you uncover the results a customer wants from your product. You must also be keenly aware that there may be different workers completing the job-to-be-done for more complex jobs. Therefore, it may be necessary to define the people involved and consider each of the results each worker expects and attempt to match your product to the results each worker wants.
Once these unmet needs - true unmet needs, found through exploring all the steps of the entire work process - are discovered, it then becomes much more likely that you develop a useful product that people want. You must be the judge of how many unmet needs you address, initially, and this will form the basis for your strategy for market penetration. Your initial solution has to be a substantial enough impact on the job-to-be-done to make switching to your product worthwhile.
People form habits in how they do things. By asking a prospective customer to use your product, you are asking that person to build new habits. For most, that’s friction and such friction isn’t desired unless the benefit is worth the effort.
In doing the above work, you will have defined your unique selling proposition that is one that your customers find compelling.
By focusing on an obvious and critical need that helps people achieve their jobs-to-be-done, that means you’ve done the hard work of understanding your customer. Alas, that’s the most significant of the goals of the proof of concept.
When you understand what motivates a customer to change his or her habits and embrace your product instead of what they do today, then you likely understand what makes your product unique compared to other solutions on the market. Assuming you’ve uncovered unmet needs within the jobs-to-be-done, you have your unique selling proposition or said another way, your product’s value proposition.
Your unique selling proposition becomes the basis for all of your future marketing messaging and will be the value that your customer readily sees as the reason to make a purchase decision. When done correctly, the decision about what makes your product unique will be easy to make, and you will be well on your way towards achieving product/market fit.
At this stage, before you’ve built a product or even a prototype, you must validate that your work has indeed achieved the end of fully understanding your customer. You must develop tests that will adequately identify if you’ve met your goal.
If you have a lot of uncertainty now, you don’t need much data to reduce uncertainty significantly. When you have a lot of certainty already, then you need a lot of data to reduce uncertainty significantly. In other words - if you know almost nothing, almost anything will tell you something. Douglas W. Hubbard -- How to Measure Anything
Whether taking a jobs-to-be-done approach or following some other path, you still need to interview, ask questions and evaluate the results. There is no reasonable substitute for understanding a customer’s needs. People use products and unless you understand what people want, you don’t have a useful product.
Questions need to be open-ended, and you should not expect others to directly give you answers to questions like, “What would you like to see?” or “What kind of solution do you think would work best for you?” The answers to these questions are your job.
Questions should be geared around getting you to a place of answering those questions for yourself. Understand the work a customer is doing by asking the right questions to uncover everything from the obvious to the secret things they do every day.
The questions you ask should, ideally, have a quantitative end that allows you to measure the impact of changes. For example, a follow-up question to understanding what a person does should often be, “How much time do you spend doing that activity?” After getting that answer, drill deeper with, “Are there ever times when it takes longer or less time?” Determine all the steps and branches along the way that would cause the work to vary.
In the final analysis, you are interested in how your product will impact the work that someone does in a measurable way. You must determine how your product fills a need, to what extent, and how it will impact the work that someone does. You will not only use this information to inform your product development, but also in informing the marketing of your product.
If there is no meaningful benefit, then you don’t have a product, because you won’t be able to sell it. As such, develop questions that adequately uncover this information.
Once you’ve uncovered the need, you also need to understand the environment in which you will do business. This will inform your go-to-market (GTM) strategy, messaging and business structure.
PART 3
Validating your product against market need is important, but not the whole picture. You must also evaluate the market environment as you structure both your product and your business. Understand:
As heard on the Build Your SaaS podcast, Patrick Campbell, founder of ProfitWell (now Paddle), discussed “the physics” of their market as the company grew. This is a metaphor for the dynamics of a chosen market.
Each market has its own unique characteristics. The market for accounting software is going to be very different from the market for an online games and very different from the market for hosting ecommerce shops. The people, needs, budgets, marketing approach, and other unique aspects will collectively conspire to make the market physics of a chosen market. The market physics will help drive your strategies.
For example, Patrick said:
Right now, in the average subscription or SaaS company, depending upon how you want to slice it, the median expenses that goes to sales and marketing is 60%… Throw in operations, you throw in like the desks and everything like that, how much money do you think is left over for retention and pricing, which are [ProfitWell’s] two paid products? There’s not a lot!
He offered their product using the freemium model in recognition of the physics of their market. He and his team understood that penetrating into companies required developing reliance upon their product that would eventually lead to budget allocation.
A company selling CRM (customer relationship management) software would have much less trouble getting access to budget because, as he pointed out, there is a significant budget allocation in that area. That market has its own challenges with very many competing products, but is still targeted to grow, at least into 2030, which is an example of an aspect of the market environment.
As you work on your go-to-market strategy, you must understand:
Marc Andreessen, from the venture capital firm Andreessen Horowitz, says:
Product/market fit means being in a good market with a product that can satisfy that market.
So what is a good market?
A good market is sufficiently large and has underserved customers with a knowledge of needing a solution to the struggles they have.
A bad market is one that has overserved customers with unrealized needs.
You might say, “Well yeah, that’s obvious.”
But is it obvious?
Viewing articles across the internet on why SaaS companies fail, the typical number 1 spot for reasons why is not having sufficient need in the market for the offered product. A nuanced reason was mistaking early adopters for a market. Either way, there wasn’t a market sufficient to support that product.
It isn’t enough to understand the market need, albeit that being very critical, you also have to have a “product that can satisfy that market.” That sounds like two things, but they are quite intertwined. If you understand the market, and it is a good market, then having a good product usually comes from that understanding - if you follow the instructions of this post - because you build a product based upon research, not a guess.
You can certainly fail at user experience, product performance or myriad other things. I’ve seen a lot of software applications that were not pretty, but got the job done, so people purchased and used them. Best not to rely on that though. Best to be in a good market with a great product.
Now that you’ve understood the market physics and whether you are dealing with a good market that needs your product, it is time to quantify the market opportunity. This can be particularly helpful when obtaining investment funds from a venture firm.
Even if you are self-funding, it can still be useful to determine the size of the market in order to gauge the potential for future growth, or how difficult it will be penetrating the market.
The most common term for this measure is the total addressable market (TAM). There are other measures that attempt to address nuanced factors, but the goal of all is gauging the scale of the market.
For example, the total addressable market might be limited because of geographic limitations or governmental restrictions. There may also just be practical limitations of the ability for a particular company to reach beyond some constraint, such as language barriers.
Whatever the circumstance, the exercise should involve a realistic expectation around how much of the market can be obtained by a single company in some unit of time. Expecting to obtain .01% of the global marketing technology industry, for example, might on the surface seem like a conservative goal, until you realize that the global market is 344.8 billion in US dollars in 2021. While that represents the total addressable market, a small percentage of that still places a company in the area of multi-million dollars of revenue, which is impractical in even the first few years.
A more realistic approach in determining the dollar estimate market share a single company is likely to obtain, would be to use the estimated price of the product, multiplied by the total number of customers that might be realistically obtained in a given period. A typical measure here would be using the average revenue per user (ARPU) and multiplying by the number of users. If the period is 1 year, then break that down to quarters or months. You get more realistic when you try to estimate how many customers you can get in 1 month. Roll that estimate up to 1 year, or 3 years or 5 or 10 and allow for a realistic multiplier of ability to gain customers as the years go by.
If for purposes of talking to investors you want to determine your total addressable market over the next 10 years, first estimate year-over-year customer acquisition growth, less a realistic estimate of customer churn. Believe it or not, people will leave your product for all kinds of good reasons, even if it is the best thing ever invented. Use those numbers to determine a realistic user count and multiply that by expected ARPU. This average might take into account different price tiers, for example. Forecasting out many years, you will also want to account for how that ARPU will change and what factors will influence it, such as inflation and expected differences in product offerings.
The point here is that it is not realistic to simply utilize some percentage of the estimates on the size of a particular industry. What is realistic for your particular company’s performance is more useful.
The professional qualities and experience of your team, the presence or absence of an applicable following of people, technology availability, competition, funding and many other factors weigh heavily on your company’s year-over-year growth potential. Mark Cuban and the team he could likely assemble, is far more likely to have an accelerated product launch versus a recent college grad, all other things unrealistically being equal.
Additionally, it’s useful to utilize the statistics and information gathered in the needs analysis part of the market analysis in order to gauge a realistic expectation of revenue. Using the example of the marketing technology industry size estimate again, if your product is offered within that industry, yet the needs analysis indicated that you might realistically only access about .2% of that total global market, then that becomes a cap on your estimates.
In other words, you determine that your product is not useful to 99.8% of the global market of that industry, then your TAM is no more than .2% - maximum - for the life of your product. This may impact your decision to enter that market depending upon the type of company you want to form, as I’ll discuss next.
Your goals for the type of company that you will establish has a direct impact on how you interpret the results of your market analysis.
Is your company going to be a high-growth venture-backed company, or will it employ only a few employees that place personal time as a high value and limit the investment going back into the company in favor of enriching company owners?
In the former case it will be crucial that there is a significantly large available market, that is forecasted to be growing, or at least not decreasing. The goal will be to obtain that portion of the market as quickly as possible. Investment dollars allow you to move more rapidly, and it will likely be expected that you do so.
The competitive landscape will be more important for high-growth companies. It may even be necessary to re-purpose the product within other industries? A venture-backed company may find it necessary to sell only to enterprise companies in some cases?
In whatever the way the company is structured, it is important to understand the market. The larger the opportunity, the better for both company structures, or any between the two. For a company that stays small, a large market opportunity simply means that the ability to sell should be easier. In the case of the fast-growing company, a larger opportunity isn’t just a nice thing, it is a necessity for reaching its goals.
Your business model should compliment the temperament, skills, values and goals of the founder(s) and likely also the management team. A recognition of the speed at which the company should grow, anticipated multi-year plans and exit plan should also be agreed to and a commitment made to the decisions made.
The market environment will contribute to these decisions. The decisions will also impact the way in which the company shows up in the marketplace.
In understanding the competitive landscape, you may want to draw from the jobs-to-be-done theory? Competition exists not just from other companies that are similar to yours, but also from other solutions a customer might employee to get a job done. A very thorough analysis of your competition might include listing all of our competitors and alternative approaches to completing the customer’s work and then indicating which features are present in each alternative in a matrix format.
When using the jobs-to-be-done theory, you would look at what others offer in terms of desired outcome achieved by the job executor. It is not about what features are available in a given solution. The features provided may or may not provide the utility of helping the customer complete the work the customer is attempting to complete, or in achieving the desired results.
Rather, it is better to look at it from the perspective of what desired results the job executor is attempting to achieve from the job. Using surveys, it is possible to determine the importance and satisfaction of various desired results in order to achieve an opportunity ranking that highlights those results that are under or overserved by competitors. This makes for a more data-driven approach to finding gaps that can be filled with your own product.
This kind of information will also provide a way for understanding your competitive environment and whether you stand a chance of unseating a competitor. Of course, there is a lot more to a complete competitive analysis, such as studying their marketing, pricing, offers, amount of funding and the like.
Another environmental consideration would be the product life cycle stage for the type of product you will be introducing.
If the type of product that you will be offering is in its infancy, in terms of product category - a new technology or way of doing work for which people are not yet familiar - your competition might be light, but you’re sales and marketing will necessarily be heavy. You will need to educate customers on the rationale for utilizing your product.
If however, you find yourself in the product life cycle stage of growth or maturity, then opportunities will likely abound.
The strategy that you employ should align with the product life cycle stage in which your product is currently.
As Theodore Levitt wrote, back in 1965 in the Harvard Business Review, product originators will have to bear the preponderance of the costs bringing a product to market. They also bear the most risks.
Conventional wisdom would have it that not having competition is an enviable position in which to find yourself. Especially if you are self-funding a product’s development, this is certainly not the case. Having similar prior products in the marketplace means that you have an opportunity to see what works and doesn’t work in terms of product features, advertising, marketing, pricing and likely a number of other otherwise uncertain aspects of product introduction.
Walmart, Kroger, and Costco all have one thing in common that can teach all inventors a great lesson – being “second” to market can make you a winner! – StartupNation
When you’ve:
Your messaging to the marketplace will be quite obvious. That doesn’t mean you won’t have to tweak it, but the understanding you have of the problem space, the jobs-to-be-done, the desired results, the way in which your product is different and aligns with the needs of your customers will give you a clear understanding of what your customers need to and want to hear.
PART 4
No product yet, but you still need product validation!
If you performed the market validation, you are now at an enviable spot that increasing numbers of product founders find themselves in, but that still many skip. You know what the customer wants and if the market will accept it. Armed with this information, you are now in a position to start deciding what features are most important for the application.
So many conflate the idea of market validation and product validation. I love that Tamara at Creidea gives two definitions for these two concepts. In market validation, you want to establish the need for your product. You want to understand the job and the steps in the job that you’re improving with your product.
In product validation, you want to understand how you will improve the lives of your customers. Did you spot the difference? Loosely, market validation speaks to “what” to improve and product validation speaks to “how” there will be improvement.
Keep in mind the stage we’re in. More on this in a moment, but keep firmly in mind that you are not yet prototyping. There’s preparation going into that stage, and that’s what we’re doing now.
Again, many seem to think of prototyping as the first step in product validation, but I don’t believe it is. Rather, you must first be concerned with locking in what is needed before you start creating how the thing you’re creating will work. How can you describe something before you know what it is?
At this stage, you need to pick individuals to talk to that are end users, or those responsible for job fulfillment. These are the people who are performing the work, whose job will be impacted, presumably beneficially, by using your product.
You have a firm understanding of the work that is accomplished on a daily basis, and you likely have a firm vision of the ways in which your product can help. Before you start building anything, you need to discuss the ways in which you feel like you can help.
As you discuss your product, resist being excited about it. Resist “leading the witness” towards answer you might expect or want. Ask open-ended questions like, “We have a hypothesis that having a feature to ease your burdens in doing X would save you N hours and prevent Y hardship each day. Can you tell me what we’ve missed? How would you express that differently?”
Notice that I didn’t say, “Our research shows…” and I didn’t say, “Do you agree with that statement?” Instead, those questions encourage disagreement and open discussion.
“We have a hypothesis…” might actually be too leading. At this point though, you’ve already asked the really open-ended questions that lead you to the understanding you have, so you need to start challenging your conclusions. It is now time to get these ideas in front of others to poke holes into them.
Resist the urge to start drawing out user interactions at this stage - sketches of what the product might look like. This can’t be stressed enough. This is not the prototype stage. Don’t treat it like it is. Don’t get ahead of yourself. Talk about the ways in which your product might help, but don’t discuss how it will; the actual interactions with the product.
You want to focus on the benefit that it would bring as in the aforementioned question, “Ease burdens in doing X and save N hours…” These are benefits, not features. This is “what” your product will do, not “how.” This is also how you should talk about your product in marketing. Features are not compelling until someone understands the benefits. There are lots of ways to do something, and you don’t want to split hairs, at this point, about how something is done before you’ve guaranteed that a particular problem needs improvement.
Also meet with product buyers. If the product buyer and the person(s) performing the job-to-be-done are the same person, then be sure to cleanly conduct two different interviews and make it clear what role you want represented. When the buyer is a different person, you want to interview that person too and understand what criteria would be used in making a buying decision. Don’t sell your product. Ask if specific benefits are important as a buyer and if so, then what kinds of benefits would be helpful. Product benefits can include ease of purchase or certain purchase benefits as well as the core product benefits.
There may also be individuals that are responsible for what the jobs-to-be-done theory would refer to as consumption change jobs. Consumption change jobs are activities that a product owner will need to employ surrounding the use of your product. This can include things like installing, learning to use, interfacing, and maintaining. There may be individuals that are very critical to the activities that your product will help streamline that also need to be interviewed.
Again, you may have found out that there are certain benefits that are needed in order to improve the work being completed. Some of those benefits might include some of these consumption change jobs? To the extent that they are, you will want to validate your product ideas surrounding the consumption change jobs.
For example, interfacing with internal systems of a company that wants to utilize your product may be a significant and important piece in integrating the product that you offer into a company’s processes?
It is important to understand the user’s desired results in utilizing your product. From this understanding, you can start to envision the types of things your application will need to do. Again, thinking about benefits, you are going to want to list the benefits that your application will achieve. These benefits should be directly pegged to the results that your users require.
A good exercise here might be to think about how you would be communicating in your marketing collateral. Speaking aloud to yourself, or to a team member, about all the great things that the product will do, and imagining that this communication is what you are putting on your website and ad copy, is a good way of testing whether you are actually dealing with benefits or features.
Of course, it is still possible that you might be thinking in terms of features. So when you or imagining this marketing communication, suppose you are talking to the CEO of the customer company or some other customer executive who is often not terribly concerned with features. Is such a person convinced that your product is worth purchasing because of the benefit that it will produce for the company?
Ultimately, these benefits should also align with the desired results that the product’s users will want to see in your product.
After all of these interviews, communication and tests, designed to ensure that you have helpful benefits that will be appealing to a customer, satisfying their desired results, it is now time to finalize your list of what needs to be in the product. Remember, this is not a list of features. This is a list of needs that the customer has and the product will provide.
Ideally, the needs list will follow a standard format that includes two elements for each need: what is needed and the desired result. That way you are justifying each need with a desired result. If you cannot find a desired result to match the need, then you are adding additional scope that is not needed.
You can think of this as the benefits scope. Be realistic about how much benefit is going to be attained in the early versions of the software. At this point you are thinking about the benefits that you want to communicate in the prototype and implement in the MVP.
If you have additional needs and desired results that you want in the product, but that are more than necessary for an MVP, then put that in a separate backlog needs list.
You can think about how much will be available in the MVP at this point, but resist thinking about it in terms of features. I’ve brought this up a lot, but I just cannot stress it enough.
It may seem moot in some ways to not think in terms of features, but it is absolutely critical that you think in terms of benefits at this point. Your job right now is to make sure that you have everything necessary to improve the lives, profitability, productivity or some other aspects for your users. If you think in terms of features, it will be very easy to miss an important benefit.
If I haven’t convinced you that this is a good use of time, then think about it as time spent developing your marketing messaging. You are going to need to do that anyway, so do it now. As mentioned previously, your marketing message should be about benefits and not features anyway.
Now that you have a pretty firm grasp on what people are going to want from your product, you can now start to think about the types of technology that is going to be required for the product. Given that you are not looking at specific features at this time, there may yet be some technology that is not completely understood as being needed, so this will need to be revisited again later.
Even looking at it from a perspective of needed benefits, you should probably have an idea of whether you will need atypical or complex technology or technology that may be time-consuming to get set up, such as for example:
In this step, you are pegging the benefit to the technology needed to produce that benefit. That way, if you find later that the benefit has changed, then you are ready to modify the technology as well, because it has a hard association to the benefit that is maybe no longer in play.
After you figured out what technology you are going to need, you may want to consider whether there might be a need for some sort of technology validation. That’s what I will cover next.
PART 5
Is your technical solution viable? Remove doubt with a technical proof-of-concept.
A technical proof-of-concept is not for everyone. Whereas it is always critical to test whether the market will be receptive to your product, it is not always necessary to test the technology that you will use to build your product.
A technical proof-of-concept is a method for testing whether a specific technology will work for the particular use case that you are considering using the technology for.
If your development team has already developed something similar to what it is that you are endeavoring to build, then there is likely no reason for a technical proof-of-concept. You will want to work with your technical team to decide what is perceived as the best course for proceeding.
As with the market proof-of-concept, your primary goal for conducting the technical proof-of-concept is the reduction of risk. You want to identify the most risky of the technical work to be done on the project. Consider whether the development team has experience in the given technical work, or even if they have had experience, are there new frameworks, integrations, changes in the use of platforms or anything else that is different from what was typical for the team in the past.
Suppose for example that your team is quite familiar with using AWS (Amazon Web Services) for hosting applications, but for whatever reason you have decided to use GCP (Google Cloud Platform). If the only difference is that you will use a single server from one provider instead of the other, then that is not very risky and likely not cause for concern. If however, you will be using their API to launch servers and allocate storage, then that is something for which you may want to consider developing a proof-of-concept?
Let’s use an example of a time when someone might endeavor to create a technical proof-of-concept. Suppose you have an application that needs to identify content within an image. Specifically, suppose the application is looking for images where people are active in a sporting event. You would no doubt utilize machine learning for this activity. You therefore need to train a machine learning model to identify these types of images.
Your development team might be interested in determining, for example, whether there is adequate source material for training the models required to identify all of these sporting events that you want to identify. In our fictitious case, the team might elect to narrow their initial test to just looking at folks playing tennis? The development team would then set up the infrastructure necessary to perform a test at identifying people playing tennis.
If your team has previously done this, or an equivalent activity, then a proof-of-concept would likely not be necessary.
One of the benefits that is sometimes overlooked in considering performing a technical proof-of-concept is the potential quality improvement in subsequent development. Especially when developing using a newer technology, there can be multiple attempts, and different code utilized from different examples on the internet.
If a bunch of code was created, it can sometimes become difficult to separate the failed attempts from the successful ones. This can lead to messy code that later on can be difficult to maintain.
Even if the code is fairly clean, it is quite typical that learning continues in the next few times that a new framework or way of developing is employed. Each time a developer develops something, they typically get better at figuring out the best ways to develop something. So by creating the proof-of-concept and then later creating a draft of a production-ready implementation, the odds of the production code being much better than the proof-of-concept code is quite high.
If there are others involved in the development of the SaaS product, a side benefit of developing the criteria for what needs to be built, detailing what technology is most risky, and then communicating that, is that it necessarily increases the amount of communication within the team. This communication can help to uncover misunderstandings or expectations that are not in alignment.
With a new project typically comes a new project team. You may like to think that your project team is going to be firing on all cylinders from day one, but that is not what should be expected. Instead, those who study the topic would tell you that there are four phases a team goes through: forming, storming, norming and performing. Without going into all the details, as there are excellent articles describing this process, suffice it to say that there is a need for surfacing a myriad of understandings which may be quite different from one person to another.
Uncovering what technologies folks want to use and for what reasons are sometimes quite involved discussions. Don’t shy away from having those discussions now. This is precisely the time when you want to understand everyone’s expectations. You are attempting to bring form and shape to your future product.
In a proof-of-concept you are in fact focused on concepts, as implied by its definition. In this stage, you want to move from concepts to concrete ideas. As you understand what technologies you are going to use, that helps you to move into a more substantive direction.
Have you ever experienced times when you were thinking really hard about a problem, and then you went off and did something else, maybe even for days, and then when you came back to thinking about the problem, you had a brand-new perspective and creativity that you had not had before? For many, myself included, this is a common occurrence.
I don’t know if I can identify the psychology behind what is going on, but for me and many I know, I get stuck in some sort of loop that limits my creativity. As Kelly Marie points out in her article, “When It’s Okay to Wait for Inspiration,” you must respect the creative cycle. She points out that,
We take in ideas, we let them roll around in our brain as we play with new arrangements, we make something, and then we rest before starting over.
When you create the technical proof-of-concept, and then later come back to the prototype or MVP stage, you will likely have a fresh way of looking at the problem space. That may even cause you to repeat parts of the proof-of-concept because you may have a brand-new concept that you might feel the need to explore.
Of course, you don’t want to fall into the trap of allowing perfection to be the enemy of “good enough,” but you also don’t want to ignore inspiration that may really set your product apart from others. It may be that differentiator that product founders and business owners look for in order to get a strong foothold in the market.
It is quite important that you identify what constitutes a successful or unsuccessful proof-of-concept. Oftentimes, developers very much enjoy developing software, especially if it is something they haven’t done before, or they are using a tool, framework or language in a new way.
If you don’t provide some sort of stopping point, then that developer may continue developing for quite some time, continuing to explore and learn, perhaps thinking that additional information would be helpful.
In this example, you may set some sort of success rate percentage of identifying tennis players in images? Realistically or not, you might determine a stopping point of the proof-of-concept when predicting with 98% accuracy if a picture is of a tennis player.
When your team has hit the success criteria and determined that it’s time to stop creating the proof-of-concept, this is now a good time to analyze the results of your work.
Keep in mind that the proof-of-concept is a tool for learning. As a result of this learning, it may become obvious that there are additional lessons that need to be considered. To the extent that it seems reasonable and economically feasible, additional technical proof-of-concept tests should be conducted.
WRAP UP
Armed with all of this information, go or no-go? Follow the path you've made
Give me a go / no-go for launch – Ed Harris playing Gene Kranz in Apollo 13
The proof-of-concept is the most significant of the steps that you can take as you work towards a product launch. If you are too optimistic in your conclusions, having evaluated the data that you have collected with rose colored glasses, then you have set the stage for a frustrating and expensive lesson.
At this point you should have:
At this point, you are now ready to reflect on all of these things and decide if you should:
If you have accomplished the above things listed in the go / no-go list, finding a positive result in all areas, you will have outlined the best possible path towards success. Success is not guaranteed, but you have done your part in reducing risk as much as possible. You have outlined the reasons why a prospective customer would develop new habits by purchasing and using your product.
Congratulations, you are ready to move forward and follow the path you have outlined!
At this point, it is important to develop the relationships you need to complement your abilities. The steps that you take in the prototype and in the MVP stage will enhance or detract the odds of a prospective customer deciding to use your product.
At this point, the most you have developed will have been a technical proof-of-concept. Your interviewing is not over yet. In fact, you have quite a bit of interviewing in your future. You will need to develop relationships with people who are willing to take time to give you feedback on:
Without counsel plans fail, but with many advisers they succeed. – Proverbs 15:22, ESV translation
You may have found that some areas did not produce the kind of results that you had hoped for. Is the project idea still salvageable? In fact, you may have come to the project with an idea, and then found that the idea really did not suit the work being done. If that is the case, then you are truly in a good position to pivot. Assuming that you have found a problem that you were not planning to solve, yet it is significant enough to build a product around, then pivoting to a product that provides the results that your prospective customers might be looking for is an excellent idea.
You may find it useful to work through all the steps again to make sure that you did not miss anything, given that you were not initially planning to move in this direction. You probably do not need to be reminded that investment is on the line. I can’t stress enough the importance of the proof-of-concept. The best way to tip the scales towards failure is to skip a proof-of-concept or to not spend adequate time in this stage.
Your pivot may direct you towards a different market? If that is the case, then it is particularly important to go back through the business portion of the proof-of-concept phase.
If this turns out to be your decision, please don’t feel dejected. This is a really good thing. You went down a path and discovered that the path would not be profitable. So many people build something, having invested tens of thousands of dollars, only to find out the same thing you did with a comparatively minimal financial impact.
It is tough to start a business and difficult to launch a product correctly. You dodged a bullet. Don’t second guess yourself. Assuming you did the proper research, the data isn’t lying to you. It was probably a great idea, but the market just doesn’t appreciate it. Given the experience you have, you’ll be that much better at spotting a good idea the market wants next time.
The proof of concept is an important step that everyone considering launching a product needs to take. Guessing about what the market wants is a costly endeavor and sadly what happens all the time. Be the smarter business person and perform the proof of concept before deciding to commit investment dollars.