Introduction

An indicator species is a group of species whose status (function, population, health, etc) can reveal the underlying health of the ecosystem they inhabit. Understanding the health of an ecosystem is a complex goal. There are many factors that contribute and impact a system’s health. The presence of an indicator species makes the diagnostic goal of determining the health an easier task.

For the Chihuahuan Desert, the Agave Lechuguilla is the most common indicator species. The Chihuahuan Desert is the largest desert in North America and one of the most endangered. Centuries of cultivation has badly damaged the ecology. This damage is revealed in the health of the Agave Lechuguilla in particular ranges of the Chihuahuan Desert.

The Agave Lechuguilla is a hearty plant with six-to-eighteen-inch dagger like leaves. The structure is like most agaves in spirit. The plants propagate in families by sending shoots out to create a child. As a result, they tend to dominate three thousand square feet when healthy and undisturbed. Conversely, overgrazing, and off-road vehicle use will disturb this growth. Similarly, soil disturbance from water redirection or cultivation will similarly disturb the sprawl of this species.

The Chihuahuan Desert is not only indicated by the Agave Lechuguilla, but also relies upon it as a critical input to the system’s flourishing. Humans have long since used the plant for a variety of purposes. For example, the fibers are strong and thin and, therefore, have been used for clothing, ropes, baskets, etc. The hearts and blooms can be roasted and eaten as well as fermented into drinks. The roots can be used for soap and have antiseptic properties. As a result, the presence of Agave Lechuguilla remains are also an archeological indicator of past civilization health.

Every ecosystem has indicator species. And all good researchers, whether biologists, archeologists or otherwise, look to indicators to simplify the complex task of identifying health in an ecosystem.

Software companies are both an ecosystem on their own as well as participants in a cultural ecosystem. They are a complex balance of initiatives, demands, resources, and opportunities. And much like the Chihuahuan Desert, even small amounts of damage can have disastrous and long-lasting implications. Conversely, when operating in its unique balance, software companies are beautiful creators and maintainers of value for founders, customers, employees, and investors.

Product efficiency is one of the many indicator measures of software companies. The health of product efficiency can mark the health of the software company. And while the final exit amount can suggest some form of health, it is a poor measure. Exogenous factors and market madness can conflate or depress the valuation to render it useless in measuring underlying health. Product efficiency, among a few others, however, shows the underlying health of the organization. The following are a series of essays on or about product efficiency.

1.1 Building the Product

Start with the customer

Thesis: there is no greater task for a B2B software founder than to know the customer using and benefiting from the product.

Branding, scaling, growing, team, culture… there are thousands of things to think about when growing a B2B software company, but only one truly matters. This doesn’t mean the other things don’t matter, but rather if a founder gets this wrong, then Bowser wins… game over.

The main thing is the product must satisfy a true customer problem. This sounds hopelessly simple and reductionistic; but in practice it is extremely difficult to get right. It is the core of a B2B software company. It is the heart and life blood and without it, the other functions of the body do not operate.

The graveyard of founder dreams is filled with beautiful and complete products. Many of these products are functionally complete and functionally satisfactory to the customer’s specifications. But function isn’t all. If the customer can’t see their problem getting solved by the product, then it won’t work. There is no greater task for a B2B software founder than to know the customer using and benefiting from the product.

Getting customer knowledge

The shortest put to building a product that satisfies a true customer problem is to be the customer yourself. This doesn’t mean holding a skull and invoking the bard to embody them. Not at all. Being the customer means that you have lived that problem and are an expert at it.

Living the problem is not something that you can do easily nor is it something someone can teach you. It comes from operating in an industry, seeing a problem that you personally experience, and then envisioning a solution. It means thousands of frustrating encounters with the current solutions, trying every conceivable workaround and still seeing mountains of opportunity in front of you.

At Golden Section, our primary filter on a company’s knowledge of the customer problem (and therefore their ability to meet it with a solution) comes from the founder’s personal lived experience with the problem. Anything less takes a lot of convincing for us to get comfortable. We expect that the cost to acquire that knowledge and perspective will far outstrip our ability to finance the company and make the entire project unprofitable.

Why is customer buy-in so important?

The first few decades of software development were characterized by extremely high cost and taking customers from people driven paper processes to the easily superior electronic twin. Computation became automatic and accurate, and organizations flattened. These early wins created new opportunities for the second and third generation of software companies. Each generation could dig deeper into a niche and develop a system with a more natural language, hierarchy, and architecture.

Where the first inning of the software revolution brought the novelty of computational power into the enterprise, this later inning is centered on customizing the fit of that computational power into the norms and culture of the niche. Subsequent innings will continue this trend and further segmentation within software verticals will continue. The natural result of this segmentation will be best in breed solutions for culturally similar cohorts of customers.

The emergence of new computing norms can disrupt this cycle. For example, in the late 1990s on-premises solutions were following this trend and the number of small niche software companies exploded. Then cloud computing became a new computing norm which birthed large horizontal players that could dominate across cultures with an easier workflow driven by the novelty of the new computational power. This novelty is wearing off (as it relates to multi-tenant software companies) and the niche operators are proliferating. The emergence of a new computing norm (quantum for instance) could cause a similar shift in this otherwise secular trend.

How to get customer buy-in

Knowing the customers and their norms is the first step in defining what to build. The next step is fitting the software solution into the norms. Selling software is selling change and people like change about as much as they’d like a hole in the head. It is friction. The founder’s job is to smooth out that friction.

If the founder has lived this problem before, then there is a camaraderie that helps smooth out the friction. But friction must be smoothed out in other ways as well. Here are a few ways that we commonly see friction in product adoption:

1. Price and pricing – This is more than just price. Obviously, price is friction you can’t remove. But the way the price is associated with the value provided and the way the pricing is conveyed are all very cultural norm-dependent for customers. Hence, price is a part of the product.
2. Security permissions and user hierarchy – There’s the way we think an industry ought to operate and there’s the way it does. These are rarely the same. The outsider will insist upon ‘ought’ while the insider will swim with the current.
3. Colors and tone of the user experience – This can be as heavy a friction item as anything. The system must meet the users where they are at now.
4. Sharing and data access – Cultures have norms on sharing and data access which may or may not make sense to outsiders. They are driven by past practice and internal stories.
5. First impression – Similar to the colors and ton friction mentioned above, but distinct in a few ways. This refers to the first encounter with the product. Some cultures need seamless interactions with features suffering; other cultures need feature optionality over ease of use.
6. Reporting flexibility – Every SaaS company has heard the request for a flexible report builder. And the novices (me included) who have fallen for it then found that feature completely unused (despite consuming a herculean portion of development resources). Some cultures are more advanced than others in their data processing capabilities. These must be weighed out and met with an apt product.
7. Interoperability and app access – Different cultures (and different products) have varying levels of reliance on a product ecosystem. This is a function not only of the cultural affinity to multi-solution tech platforms but also the depth of the ecosystem of applications serving that culture.
8. Usability – This is a hopelessly broad section. Some cultures support large contract values because the economic impact of maximizing human labor input is extremely large. For others, this impact is smaller. The impact value sets the price of the product and drives implications for training that can be delivered. Every founder wants to bring a ‘no-training-necessary’ product to the market, but in many cases this isn’t practical.

Note: this is not a comprehensive or exclusive set of friction points. It is just the set that came to mind from my experience.

The founder’s job is to craft a product that meets the culture that she is serving. This product encompasses more than just the core workflow of the product. It encompasses the sales process, the onboarding process, the account management process, and the renewal process. These are critical components to how a customer interacts with the product and, ultimately, whether the product will bask in the warm sunlight of product-market fit or languish in the darkness of obscurity. If you build it, they won’t necessarily come.

Ditches to avoid

Software is an unusual product category. The function is so closely tied to the form and tangled in the cultural norms that two products with identical specifications can have wildly different adoption due to non-specification related items that have cultural impact. If someone has a use for a hammer – a core use not an edge case – most hammers will do. A ballpeen, brick or claw, all those hammers will drive a standard nail into a 2×4. Not so with software.

Software is not just a tool. It is a tool the user wears to execute tasks. It is an exoskeleton that must ‘feel’ right to the user to gain adoption. Many founders have fallen into the following ditches when bringing their product to market. Avoid them like the plague.

Mistaking customer enthusiasm for product market fit

Startup life is sexy. The industry might be four minutes into its five minutes of fame, or perhaps the religion of startup worship is entering its own as a major world ideology. Either way, customers love hearing about new products coming to their industry. They love this so much that most large companies have innovation departments – entire groups of people devoted to finding startups and trying out solutions.

This dynamic causes challenges for founders. In the early days, founders are particularly susceptible to hearing positive news. They have staked everything on this venture (or hopefully they have). And gravitate toward friendly audiences like a fly to the blue glowing hum of the UV bug lamp. Often it is too late when they realize the audience they were chasing was either:

1. Not a relevant subset of the culture they are serving
2. Not a person with budget at the company they represent

This is toxic and extremely dangerous. At Golden Section, we have encountered hundreds of companies that fit this profile. In looking over the current install plan and the pipeline, it is relatively easy to discern the true customer fit conversations from the self-reinforcing hivemind of corporate innovation discussions.

Founders thinking, they have lived the problem

The best way to know a problem is to live it and drink it the pain and discomfort. It is rare for someone with the aptitude and capability to bring a product to market to also have the stamina and discipline to languish in pain without action. But this is the exact paradox of the situations. Founders cannot access the nuance needed without living the painful reality far past most people’s breaking points.

As a result, some founders try to short circuit this. They find a veteran of the industry upon which they hang the hat of conveying nuance. Or, worse yet they fell for the siren call of startup life and then searched for a product to bring to market. And in this search concocted a story that they told themselves enough times to manifest it at real in their subconscious about how they have lived this pain.

This story telling is usual for founders and can be a key part of the psychological heft needed to overcome the darkness of starting a business. But it can also blind a founder to the cold hard reality that they don’t really know the problem. This story telling is so powerful that it can re-write memories and create alternate universes.

The founders who find an industry veteran to convey the nuance miss an important point: the veteran might be complicit with the way things are. Startups are sexy right now. This sex appeal can attract apostates to the belief nominally driving the startup. The veteran rarely works out.

Founders getting too pumped about the technology

Early-stage teams will always include technical people. Even if the technical execution is outsourced, the early-stage team will include people familiar with technology and the trends upon which it rides. Founders can get too enamored with the technology they are using and it’s relative popularity and miss the need to create an actual product.

This happens at the bleeding edge a lot but can also happen in more established domains. For example, when new file formats come out there is usually a flurry of startup activity. Sometimes this is justified because the format changes deliverability or permissioning or some other way that industry operates. But often, these startups are dress rehearsals for the format and not the real deal.

This isn’t just about formats but also happens with development frameworks, computing, and other aspects of the ‘how’ behind a B2B SaaS company. Founders need to be discerning when thinking about the product. Picking the right tech stack is important but ultimately it is not the product. The product is what is done with that stack and how it meets customers where they are and delivers them a context-rich value statement that they resonate with and enjoy.

1.2 Think Long Term in Your Design

Thesis Statement: Designing with classic principals and focusing on the real product – the human interface – is essential to long term design.

Software company founders face a range of paradoxes in scaling their company. One of them is thinking for the long term in product design. How should a founder design for the long term with a temporary material? It’s like asking an architect to build a classic landmark out of papier-mache. How is this possible?

An economics teacher of mine used to quote Keynes’s famous line, “in the long run we are all dead.” With sufficient time resolution, all products fail. Behaviors change, hierarchies evolve, cultures shift… This is not to say there aren’t constants that can be leaned on, but that the way these constants are used by individuals changes over time.

I visited our team in Saville a few years ago. The town is stunning. The architecture seems trapped in time and the walled gardens seem straight out of a Shakespearean play. Of particular interest is the Catedral de Sevilla (aka Cathedral of St Mary and the See or the Seville Cathedral) which towers across the street from the Puerta del Leon (the more modern entrance to the Royal Alcazar of Seville).

As the seat of power during Spain’s time of world dominance, Seville images the wealth of a bygone era. No buildings more represent this than the Seville Cathedral. Towering 138 feet above the street and covering 124K square feet, the Cathedral supplanted the Hagia Sophia as the largest cathedral in the world when completed in 1528.

The architects, Alonso Martinez et al, clearly had legacy in mind when building this behemoth. It is breathtaking in size, scale, and beauty. They were designing it for the long term. But for what function?

Cathedrals served several functions. In Christian practice, a cathedral is meant to hold and shelter a congregation for corporate worship. In political practice, however, the cathedral imaged political power and wealth. I some cases it served as a center of commerce for a region.

But despite these varied functions, the Seville Cathedral now serves as a tourist location. It no longer performs its designed purpose. A visitor might notice a pious observant in prayer or two, but the lion share of the visitors are there to behold what used to be; what was.

The rigidity of the design and the materials used, as well as the incredible cost, all serve as anchors to prevent the Seville Cathedral from morphing into what the culture around it needed. The Spanish economic might waned over time, the monarchy lost power, the church lost power, and the congregation dwindled. The culture shifted; the building stayed the same.

Thinking long term in design is mostly about flexibility. Software products are short lived creatures. When designed right, the human interface – the way the product enhances and stimulates human potential – should far outlive the digital manifestation of the interface. So, what is necessary for designing long term software solutions?

Principles of software design

Well-designed software should be as small as possible to achieve the proper human benefit. This can be expanded into the following design points:

• Small as possible
• Efficient with resources
• Unique
• Contextual
• Inclusive
• Collaborative / comprehensive (i.e., it works across all workflows)
• Value oriented
• Extensible

This list is esoteric and philosophical; and not as small as possible (ironic!).

Small as possible

Software cost is a function of size. Not only the initial build, but the ongoing maintenance. This is not a strict rule. It can cost more to build a highly efficient product, but in the longer term the efficient product will have less maintenance load than the larger product.

The maintenance liability tail isn’t the only reason to make software products as small as possible. It is a waste to build a product bigger than it needs to be. Furthermore, the qualifier “possible” suggests that it is built to the appropriate size, not larger. One benefit of this is it makes the psychological cost of walking away from the manifestation of the product easier.

Sunk cost fallacy is real. It is cognitive friction that costs energy to overcome. It isn’t easy. Smaller products are easier to drop and replace. And sometimes’ that is necessary. After all, the actual ‘product’ is the human interface, not the way it manifests on screen in this version.

Efficient with resources

Well-designed products are efficient with resources. Software products require and consume resources. From computing resources to energy to mindshare, magnifying human potential is resource intensive. Good products are efficient. They use the minimal amount of resources to achieve the desired result.

Here is a subset of the resources that a good product will use efficiently:

• Computing power
• Data storage
• User attention
• User clicks
• User’s memory
• User capacity for focus

There are more resources to add and more that will be added over time.

Unique

Good products are unique products. Uniqueness isn’t just a requirement for competitive advantage, but it is also a requirement for efficiency. Repetitive human interfaces serving the same culture is a waste of time and talent. Good products aren’t duplicative, they aren’t copycats, they are unique.

Contextual

Good products are designed within context. The design recognizes the context of a culture: how it moves and operates. It meets the culture where it is with the added power of automation. This mix of new and old is delicate, hence the need for context.

Inclusive

Good design is inclusive. This isn’t about politics or ‘feel-good’ niceties. Inclusivity means that it is designed with the users. For further clarity, designing with the users doesn’t mean bouncing ideas off them or inviting them to sit next to your fiddle leaf fig tree and scrawl a screed on to a whiteboard.

Instead, inclusivity means the nuances of how people operate within a culture are considered and reflected. Software exists to magnify human output. This magnification requires buy-in from humans. If the product is not inclusive, it won’t get buy-in.

Collaborative and comprehensive

Good design is collaborative. This is tightly linked to inclusivity, but with a few distinct differences. Collaborative design means the product doesn’t just reflect one person’s ideas of how a culture operates, but that it reflects the culture at large. And the product works across workflows.

Cultures have many workflows, not just one. Collaborative products recognize the input processes and the output, post-product, processes, and work in synchrony with those processes. Good products collaborate across workflows so that the user doesn’t have to force a macro workflow.

Collaborative also means that the product operates well within the ecosystem of other solutions that serve the same culture. This is difficult. Often companies want to grow into other workflows instead of bloom in the workflow they own. This compulsion is not collaborative and results in tension and angst with the user. This tension kills buy-in and, hence, is not part of good design.

Value oriented

People adopt software because it makes an impact for them. This impact is value. In most business contexts, this impact can be quantified and promised. Good software products are value oriented. They recognize, track, report on, and deliver value.

In a value-oriented design process, the designer works with the understanding of how that value will impact the user, the company, and the ecosystem. The designer ensures that the value is clearly connected to the product and that the users can see, feel, and experience the value.

Extensible

Good products are designed with a foundation that can be built upon. This design principle is in tension with the principle of “small as possible.” This tension means that a product should be built to be built upon, but not built upon unless necessary. Extensibility also refers to the product’s ability to stretch. In context, this means its ability to stretch into another workflow, but not at the expense of another participant in the ecosystem. This allows the user to stretch the use of the product to the point that another workflow starts. It ensures that there is coverage and comfort in the intersection of two workflows.

Long term design

Product spend is a primary area we see founders fail. The insecurities that propel them to greatness are short-circuited and bastardized by the rigid nature of product construction. The only antidote is viewing the real product as something greater than the ones and zeros on the page. The real product is the human interface; the way that automation can magnify human potential in the chosen workflow within the chosen culture. That is the real product. And when that product is manifested with the design principles here-in laid, it gets staying power and flexibility. That flexibility means it can influence the culture, flex with the culture, and find permanence despite being built on the sandy foundation of ever-changing technology platforms and frameworks.

1.3 Get Patient With Slow Results

Thesis: Good software takes patience to form into the right cultural fit; complete with the nuances that will ensure permanence.

Patience, hard thing! the hard thing but to pray,

But bid for, Patience is! Patience who asks

Wants war, wants wounds; weary his times, his tasks;

To do without, take tosses, and obey.

            Rare patience roots in these, and, these away,

Nowhere. Natural heart’s ivy, Patience masks

Our ruins of wrecked past purpose. There she basks

Purple eye and seas of liquid leaves all day.

            We hear our hearts grate on themselves: it kills

To bruise them dearer. Yet the rebellious wills

Of us we do bid God bend to him even so.

            And where is he who more and more distils

Delicious kindness? – He is patient. Patience fills

His crisp combs, and that comes those ways we know.

Gerard Manley Hopkins

Customer feedback, competitors announced, churn, pleadings by the team; these are just some of the petty urgencies that crowd a founder’s lungs in suffocating embrace. How should a founder respond? Growing a B2B SaaS product is about managing resources. One resource is the tolerance of the founder to withstand existential feedback. “To do without, take tosses, and obey.” – this is the role of the founder. Good software takes patience to form into the right cultural fit with the customers; complete with the nuanced niceties that ensure permanence.

Founder tolerance, the fickle resource

Founders vacillate eternally between the sundrenched hills of success and the dark valley of despair. The catalyst for the journey between these poles are: existentially threatening encounters for the downward journey and confirmatory evidence for the assent. We can only handle so much time in the valley of despair before giving up. So how should a founder manage her tolerance for existentially threatening encounters?

Balance is how. Balance is knowing that you exist outside and beyond your business. It means when you encounter a threat, it isn’t a threat to yourself, to your identity. Instead, it is a threat to your business. From this perspective, the founder is bolstered against the see-saw of angst and can handle the threat with the importance it deserves.

My past encounters on this journey were ugly and, I believe, endemic to our kind. When left to its natural cycle, even mentally strong founders with natural balance and safety nets aplenty will get lost in this angst machine. We seek confirmation as the only means to escape the valley of despair. And, when finding it, however small, we cling to it as our life jacket while ignoring the signs of impending doom. We ignore the threats, which, when they manifest, kill our business and our identity along with it.

Tolerance of the existential threat comes from psychological distance with the business. When the founder has this approach, they can deal with the threat. This means assessing it, contending with it, and putting it in its proper place. Most threats that send founders reeling are best ignored. They are inert utterances of jealous minds. However, the real ones are the small signals, usually delivered timidly, of a lack of customer connection or the emergence of a competitor who can crowd out a product’s ability to connect.

Founders must learn to contend with the threats and not ignore them. This also requires working on blocking confirmatory evidence. Founders don’t need more confirmation of their business. They need to know where the product is failing. Where it is missing the mark. This requires engaging with customers. Ironically, this can create more existentially threatening encounters; hence the need to learn to contend with it.

Experienced salespeople understand that they aren’t looking for a ‘yes’, instead they are looking for ‘no’. Assuming there is a product fit with a market, then a salesperson’s job is to disqualify non-buyers and focus all their energy on buyers. The fastest way to beat quota is to disqualify opportunities. Similarly, founders are looking for problems with their product. This requires engaging with frustrated customers and hearing the problems. Founders who can’t contend with the threats will ignore these opportunities and spend all their time with ‘happy’ customers.

Slow results

Mapping a product onto a market is not an easy task. The product build process is dramatic and slow. There are two drivers to this. First is the communication problem along the specification discovery value chain. Second is the iterative nature of the build to feedback process. Both drivers are inescapable, and they are the cause for countless doomed mega startups. They are the reason most successful software stories start with several years of obscurity before hitting scale.

The specification discovery value chain is extremely long and complex. There is a product that exists in thought space that fits the defined customer culture perfectly; let’s call this the proper product. The collective of all customers in that culture know it, but no single person knows it. The more successful founders have lived the problem enough to know enough of it that they can get proper feedback.

Still though, even the most seasoned founder steeped in the problem will only build a shadow of the proper product. If this shadow is recognizable by the customers in the culture, then the feedback loop begins. However, the feedback loop requires communication.

It requires customers:

1. Know what they want to say (not an easy task)
2. Say it

Furthermore, it requires the founder:

1. Knowing what customers to ask
2. Hearing what they are saying.

This four-part challenge is impossible to execute perfectly and nearly all product problems come from a breakdown on one of these measures.

The feedback loop has one additional wrinkle: the technical development process. The founder must relay the proper product specifications to a group of engineers who will run the technical development process. These engineers rarely come from the industry and, therefore, have no context or knowledge of the nuances. Hence, another communication challenge emerges.

The founder must:

1. Know the nuances and how they differ from other products.
2. Explain them sufficiently to engineers.

The engineers must:

1. Know to ask for clarity on the specifications.
2. Build flexibility into the product for the inevitable recycle.

This iterative process is usually where products run by panels of customer experts fail.

The build process has an iterative nature. Specifications must be communicated, documented, planned, processed, scheduled, built, inspected, and then tested. These segmented functions take time and no amount of resources or hustle can overcome that. The startup graveyard is crowded with the corpses of mega-funded startups (usually funded by industry instead of institutional investors). These mega-funded startups (e.g., Quibi) ignore the amount of time required for this iterative process. Hence, the G&A burn against the dev output is unsustainable and the company burns through its cash while waiting for the product to complete.

Conclusion

Founders building a well-designed proper product must contend with existential problems. They must bolster themselves to look for the issues and ignore confirmation. Furthermore, they must get comfortable with slow results. If the processes are working and the founder is secure in their knowledge of the problem, then the task is to wait. This waiting isn’t easy, it is “where we hear our heart grate on itself.”

1.4 Better a Full Half Product than a Half-Done Full Product

Thesis: Customers don’t want the shadow of what may come, they look for the complete package. Reduce your story to fit the package you can deliver.

Bringing a B2B software product to market is a resource game. It’s high stakes, but still just a resource game. And no founder has the resources to bring a fully finished full product to market. Not only is this extraordinarily expensive, but it also is extremely risky.

In pursuit of the proper product the founder just might cement in decisions that cannot be reversed but that permanently wall out the proper product. Customers don’t want the shadow of what may come, they look for the complete package. Reduce the story to fit the package, or the product, that can be delivered.

To dream the impossible dream

No longer young… bony, hollow-faced… eyes

That burn with the fire of inner vision. […]

And all he reads oppresses him…

Fills him with indignation at man’s murderous

Ways toward man. And he conceives the strangest

Project ever imagined… to become a night errant

And sally forth into the world to right all wrongs

Mitch Leigh, Man of La Mancha (I, Don Quixote)

The opening lines of Dale Wasserman’s masterpiece, Man of La Mancha, lay a scene that is well known to most veterans of the B2B software game. The endeavor hard; the dream – impossible. And yet, founders persist. What drives this?

The dream drives this. The dream of validation. The dream of fulfilment. The dream of showing up all those who doubted and the sweet embrace of the fulfilled hopes of supporters. This propels the founder.

But in this moment of propulsion, the founder is presented with a challenging task: curtailing the product to hit an early, but complete version of a product. The urge to go wide and excuse imperfections on the core workflow is real. It is palpable and it must be confronted. It is the impossible dream. It is the siren call of glory the founder must resist.

The right product to build is the smallest valid subset of the proper product. This subset must accomplish the following key standards:

• Smallest possible product
• Complete workflow
• True value
• Cooperative
• Extensible

Smallest possible product

This standard is linked to the design principle “Small as possible.” The goal here is to carve out of the set of valuable customer experiences a small, discrete subset of value. The proper subset of the proper set will be the subset with the most definable parameters.

Often a product is made up of a mixture of valuable customer experiences that flow effortlessly and ceaselessly between each other. This mixture becomes difficult to separate. And it is the founder’s job to investigate it and see what can be extracted and isolated.

Take launching a restaurant for example. Let’s say a founder is from a demographic that she expects will value authentic Oaxacan cuisine along with high end tequila’s and mezcals. She has a unique perspective on this value proposition and a unique access to source and deliver the experience. Building the entire experience and outfitting it properly (the proper product) would cost $2 million. However, there is still a question of whether her intuition on this problem is correct.

Hence, she needs to bring the smallest possible product to the market. Very rarely do restaurateurs (or funders of restaurants) accept a partly done concept. For instance, if she only had $250 thousand to demonstrate this need, most would agree that a 10% complete concept would not adequately test the hypothesis. Instead, she needs to create a subset that is discrete, and risk adjusted to prove out the hypothesis.

For instance, she could work with another restaurant to bring a temporary menu item with drink pairings to test out the reception. Or, if the budget was larger, she could offer a private chef experience for private parties. Or, if the budget was larger still, she could launch the concept in a causal variety with a food truck. All these routes are possible subsets.

In software, we see the 10% buildout happen all the time. It is unfortunate and creates chaos. The corpse of the failed concept hides profitable niches from discovery. This is partly due to the abstract nature of software. Unless you are the customer, it is very difficult to know whether the product is a subset or a portion of the set.

Complete workflow

The subset must be complete. The customers must be using it for the value it can deliver today. Selling expectations of future product deliveries is like putting multiple liens on a deprecating asset and then consuming the cash from the lien unproductively. It locks the company into delivering loosely defined emotion driven ‘feelings’ on a timeline. This is a liability, and it is undefined in size, scope, and term.

Completeness means the product must provide value. And, that value must be compelling enough to prove out the broader thesis. Customers must see the product as it is in its smaller form and see value.

True value

The value customers receive from the product must be true. This may seem derivative of the prior standards, but in fact it is distinct. Novelty can compel adoption which hides the nature of the true value. Novelty wears off, true value builds.

The subset must provide true value. Founders can discern true value if the product is driving achieving a business objective that results in dollars of ROI. The challenge here is pushing past the surface level and into actual value.

Cooperative

The subset must cooperate with the customer’s other processes and systems. This cooperation might include data interoperability, workflow interaction, UX similarities, and so on. Subsets that are not cooperative sow the seeds of their destruction before customers have a chance to get hooked.

Extensible

The subset must be built with the broader set, the proper product, in mind. The subset is the foundation and growing from it to the proper product needs to be a consistent story and a fluid process. Extensibility includes the workflow steps in addition to the technological stack.

Conclusion

The proper product cannot be built in one push. It takes interactions with customers to fit it into the culture and into a stream of value that an enterprise can build itself upon. These interactions take time which takes money. Founders must discern the appropriate subset of the proper product to build that will be a proper test of the hypothesis that they see so clearly.

1.5 Focus On What Matters

Thesis Statement: Focus, not capital, is the scarce commodity of early stage.

Customers screaming for features, employees demanding pet projects, competitors encroaching… These are the day-dream nightmares of early-stage software founders. The inputs and feedback hurl toward the founder like a swarm of mosquitoes. It is the perfect environment for stimulating high quick-start personalities with ADHD. It is chaotic. It is devoid of focus.

Capital is a necessary ingredient for any software startup. It comes in the form of sweat equity, actual equity, customer advances, or some other ‘bet’ on the company’s success. Focus, however, is a rarer commodity, the absence of which has far more dire consequences. Focus, not capital, is the key discipline, the necessary ingredient of early-stage software.

What is focus?

In 2016, Apple announced the iPhone 7 with an enhanced camera mode, the portrait mode. In portrait mode, the aperture is opened wide to let in more light and shrink the depth of field. This highlights the point of optimum focus and blurs the background. The result is aesthetically pleasing. This mode quickly became my preferred mode of capturing people in pictures.

It is counterintuitive that rendering parts of an image blurry will enhance the aesthetic appeal. Shouldn’t the purpose of an image create clarity everywhere? The reality is that our eyes are point-devices. They need stimuli contained and served up so that the focal point is known. Absence of this structure creates chaos; it breeds anxiety in the viewer.

Focus is the simultaneous act of clarifying the purpose while removing the extraneous. This dual process makes portraits beautiful because it enables the mind to take in the purpose and not lose itself in a sea of “nice-but-not-necessary” items. Focus is the efficient use of the scare resource: the mental capacity of the founding team and the mental energy of the customer.

Nothing is effective with sufficient dilution. The most potent poison can be consumed when diluted with enough inert material. To be effective, a founder must fight dilution. This is particularly true given the odds stacked against the founder from the outset. Focus is the only path to efficacy.

Why is focus rare?

Entrepreneurs are plagued with insecurity. We are confident that we can execute, but we are nervous about the elements we cannot control. This leads us to cultivate affirmations while ignoring criticism. An ugly byproduct of this is that we succumb to the shiny object syndrome a lot. This drives us to run down all avenues in pursuit of confirmation. This exhausts capacity and spends that scarce resource where it will have a counterproductive impact.

Also, founders fail to focus because it is hard work. It means actively ignoring inputs and holding onto an idea, a dream, through waves and storms. Default is almost always wrong because active value creation takes active work. Focus is not default. It takes a decision, and that decision requires cutting something; hence, it is cognitively expensive.

Proper focus takes empathy and humans are built for self-worship. Obviously, it is possible for a company to execute on focus but to do it on the wrong thing. Proper focus, i.e., focusing on the right thing, takes empathy, seeing the world through the eyes of another person. This empathy enables founders to know what is and what is not important. Absence of empathy leads the founder to think all things are important.

Focus is dramatic. The founder is the standard bearer of their view of how the world ‘will’ operate and the product is built for that future state. Focusing on specifics of that vision means contending with different visions. This contention comes from employees, partners, investors, customers, family members… Founders must engage in the drama and persevere.

Implications of focus

Cultivating focus has implications for how a company grows. Here are a few things I believe are necessary to have focus:

What you measure matters – you will optimize the business for what you are measuring. This is just like your eye optimizing to see the person in a portrait mode picture. The business will form itself around what you are measuring. Make sure to measure the thing you want to optimize.

Focus requires saying no and yes – focus is the simultaneous pursuit of purpose and honing of the extraneous. It requires both saying yes to the right things and saying no to the wrong things.

Focus breeds drama – the artist is the only true shepherd of the finished product. Usually, this isn’t dramatic in the process because the artist is also the implementer of the process that creates the finished product. Not so with software! Founders must communicate well and expect drama when focus is applied. Focus for a software company means that team members will need to yield their artistic autonomy to the founder and implement the founder’s vision.

Conclusion

The compound effects of focus are tangible. Focused founders have less technical debt, less team churn, less customer drama… less bad stuff all around. The effects aren’t just in preventing bad stuff either. Focus produces deeper customer experiences, deeper team buy-in and stronger revenue traction. These advantages are force multipliers in capital efficiency.

1.6 Build a Robust Product Process

Creating a product is chaotic. Nothing about it is smooth or easy. In Thus Spoke Zarathustra, Friedrich Nietzsche wrote “One must still have chaos in oneself to be able to give birth to a dancing star.” Good products require dealing with the chaos, embracing it in the right way and pushing through. But not all chaos is the right kind of chaos.

When Nietzsche uses the word chaos, he is not referring to disorder but rather the space between potential and creativity. In our post-modern Western context, however, the word ‘chaos’ embodies both disorder and the creative potential to which Nietzsche refers. Poor process, unqualified personnel, logical errors, these are all examples of ineffective chaos (e.g., disorder). Embracing it doesn’t give birth to a dancing star, it gives birth to the leviathan – the embodiment of ‘disorder’ chaos.

Faced with this tension, how can an enterprising founder navigate the product development process to give birth to the dancing star without creating the leviathan? How can one know what chaos to embrace and what chaos to avoid? These are crucial questions.

Good chaos is the pathway from the safe status quo of now to the unrealized potential of your creativity. But too often, founding teams get stuck in ineffective chaos, give birth to leviathan instead of a dancing star.

Planning is essential

So many products begin without proper planning. In some ways this is inevitable. No founder knows exactly what the end-product should look like when starting out. The customers will have a say in what features matter most and ultimately whether the product is has value. But the inevitability of future change does not excuse starting out with no expectation of an end-result.

Creating a product charter or vision document is a good way to fight against this urge. It outlines the things that are important to consider. Some of these things are unknowable at the beginning. For instance, which features the customers will like most. Others are more tangible. For instance, how much downtime can customers in this industry tolerate or what DevOps expectations on reliability and performance should be pursued. These represent more tangible goals that should be a part of every product vision.

Here are some specifications of a good plan:

Product Concerns

• Key user workflow based on different roles
• Key user interactions, key transactions
• Role based access control and user permission
• Expect user volume, application performance and uptime
• Regulatory Compliance (i.e. HIPAA, PCI etc)
• Support / customer success interface
• Usage data needed and dev-ops interface

Process Concerns

• Repeatable and effective development process (e.g. Scrum)
• IT tools that support the adopted development process
• Adopted development process should fit the current stage of the company (Minimum Viable Process for Minimum Viable Product)
• Team roles and responsibilities, specialization and collaboration
• Establish development metrics
• 5-year staffing plan

Diving into development to build a product without a minimum vision document that satisfies the checklist above is sure to create the leviathan rather than a dancing star. We have witnessed teams still reeling from the negative side effects of a hasty start years after the product launched. This is one of the most critical points of leverage in an R&D organization.

Process discipline around the plan is also essential

Listening to ‘the wind’ might work for Cat Stevens, but it doesn’t work for a multi person engineering organization. An organization is made up of individuals pursuing a common aim. This common aim needs to be defined. For an R&D organization, this is a product roadmap. It specifies the sequence that the product vision will be realized.

For early-stage teams, a roadmap might seem like a useless exercise designed to make investors happy and check a box for funding. This couldn’t be further from the truth. It ensures that everyone on the team (even if the team is just two people) understands the order of priorities.

The roadmap must be accompanied by a product roadmap meeting in which the key constituents of the company can vie for their perspective of what is most important. Sales will push for features, dev-ops and support for reliability, and the executive team will push for perceived competitive advantages. At the intersection of these competing tensions is the dancing star. When one of the voices is too loud or too intransigent, the leviathan starts moaning.

When ‘the wind’ controls this process, the result is chaos leading to the leviathan. Experienced founders have witnessed the chaos created through the sales team hijacking the roadmap. This is one of the more common ways a process results in the leviathan. The product initially may succeed in achieving the sale, but the lack of reliability results in a hostile customer base. Conversely, technical founders can often fall into the other ditch by continually building reliability into the product at the expense of customer-facing features. This results in no sales which is just as bad a result. Mediating this tension is the role of the product roadmap process.

Who is running the process?

There are two ends to the spectrum of poor product control. On one side of the spectrum are teams that follow the age-old mantra that “the squeaky wheel gets the grease.” In these organizations the product creation process is hijacked by self-interested sales team members and loudest customers. As a result, the engineering team is forced to work on urgent but not important issues. This puts the product in a continual state of catch up.

The other side of the spectrum can be best illustrated by what Alan Cooper described in his book: “The Inmates Are Running the Asylum.” On these teams, engineers are deciding what to build. These teams result in products that have a lot of cool new tech features, but they don’t meet customer expectations or provide meaningful value.

The mission of product management is to achieve the balance of above two tension. Always work with customers and the tech team to find product market fit, shield engineers from sales, and help the engineering team focus on addressing the important strategic items one iteration at a time. The best way to achieve this tension is through a well-controlled roadmap.

At minimum, a product roadmap process must have the following components:

• Product roadmap meeting frequency at least every quarter (monthly for early stage)
• Roadmap ‘resolution’ should show no more than 3 sprint cycles in one unit
• Each module should have a swim lane as well as reliability having its own lane
• The roadmap should have an ‘owner’ in the company that is responsible for versioning the roadmap after each meeting and controlling the file of the most recent version

You will never outgrow the need for process (or be too small for it)

Poor inputs can easily result in a bad end-product, but more teams fail by ignoring process than by using poor inputs. A founder once expressed the desire to get directly with a few of our engineers to ‘hack out the product’. Knowing that this process would unleash the leviathan, we politely refused. Three years later, the product was still nascent. Good process on its own will not birth the dancing star, but bad process will surely unleash the leviathan.

The right processes in the R&D organization can reveal bad inputs quickly and ensure that the elusive nature of R&D can be benchmarked and compared to best practice output from other organizations. Skipping this step at the early-stage results in the loss of critical data on how the company’s R&D organization works which becomes crucial when scaling the R&D organization.

Early-stage teams are not alone in shirking process. Golden Section has engaged with firms that are advanced in revenue and funding that are still too lite on process. This makes the engineering team impossible to benchmark and it puts them into a constant fire-fighting process. The justification is always the same: “we don’t have the time.” This justification has been used across the spectrum from organizations with $15M+ budgets to single founders. And it is wrong.

Most organizations will find that they don’t have the time to not create and follow processes. The positive benefits of preventing downstream errors alone will more than make up for the inconvenience of an extra meeting or writing meeting minutes. Most importantly, founders often forget that buyers are acquiring a company’s processes and customer relationships, not its people or product. Getting the processes right has tangible ROI.

The minimum requirement for a good engineering process (or product realization process) includes the following:

• Daily standups (or check-ins) within teams (i.e., not organization-wide) with agendas and minutes (no minutes saved = meeting didn’t happen)
• Sprint review meetings with minutes (retrospective focus on prior sprint)
• Sprint planning meetings with minutes
• Tracking the success or failure of each sprint (above 90%)
• Measurement of development velocity
• Quick fix engineering (QFE) on its own process (i.e., outside the sprint)
• Clear ownership and ticket progress through at least: product owner, business analyst, technical team lead / sprint manager, development, development testing, QA, deployment.
• Minutes tracked on every meeting with attendance, description of barriers, action items with owners and outstanding action items from prior meeting
• Non-conformance report for every post-production defect to link to a ticket (or tickets) and a root cause analysis

The quality of your human capital is essential

There are few things more likely to conjure the leviathan than a non-technical person hiring a technical person. The potential for chaos is extreme. Yet, founder after founder hire the technical talent, they ‘think’ looks like the right person. Reliance on heuristic and gut instinct from people who are talented in this space is still a bad idea, but it can be fatal when that reliance emerges from a novice.

One way to get around this is testing the talent during the hiring process. For experienced organizations, testing will be in-depth and involve sophisticated and proprietary set of questions and review of competence. Early-stage teams are likely to have no testing at all. Ironically, experienced organizations have the capabilities to hire inexperienced talent and train them into productive team members while early-stage companies do not have that luxury. This means that a good technical review of a new hire is even more critical for early-stage teams.

At Golden Section, we have seen dozens of companies fail due to a revolving door of technical personnel. Some of the turnover can be explained by culture fit or personality types, but often it is due to a lack of technical competence. This issue often masquerades as other things. People do not like doing something they aren’t good at doing. It is innate to humanity to search for life giving work. As a result, poor technical hires will not only result in a more expensive and less reliable product output, but they will also turnover with higher frequency.

Our assessment process fits in the ‘experienced organization’ bucket and, as such, is likely too extreme for most early-stage teams. Therefore, we recommend the following as a minimum requirement set for assessing technical fit:

• Resume review of past employment and projects for technical knowledge
• Technical inspection of past work product (high quality technical hires will have a body of work that can be inspected) – make sure an expert is reviewing the work
• Technical assessment (like Hacker Rank for example)
• Fit assessment for not only the languages and product type planned but also with the rest of the product vision document

There is a gulf of difference between the engineering roles present in large teams and those in early-stage teams. Knowing these differences and how to hire the right engineer is challenging. Golden Section assists our clients in making those hires to increase the probability of success.

Role segregation vs the ‘full-stack’ is key

Role segregation is essential for any robust engineering organization. The ‘full stack’ myth is mostly unique to the early-stage company. Sometimes it can be found at larger organizations within small teams or new product areas. But in all cases, it is the symptom of a myopic perspective. The rise of the ‘full stack’ myth has conjured the leviathan in countless companies.

‘Dancing star’ products are the result of good engineers working with good processes on good customer user stories that come from valid and important customer requirements. Those engineers work in a coordinated way to assemble the product. Role segregation is key to this equation. Alternatively, by requiring each engineer to manage the entire stack of one slice of the project is akin to hiring handymen to collaborate on building a two-story house and giving each of them one room to build foundation to roof. Such a process would result in doors not aligning, walls not meeting, ceiling heights not matching, and more. Furthermore, by hiring handymen who can do a little of a lot of processes, the quality of the total output is certain to be impaired. The result is the leviathan.

Role segregation recognizes the company will grow. The future state organization will be able to scale up back end, front end, and QA with ease because the necessary organizational practices appreciated these roles. New hires will have a body of work to start with and a well-defined place in the organization to embody. In addition, role segregation ensures that the proper processes are more likely to exist and be followed.

Golden Section recommends that all teams have a person (or persons) in each of these necessary roles of a high functioning product engineering team:

• Project Manager – Responsible for sprint process including staffing team appropriately, planning & executing user stories among the entire agile team.
• Product Manager – responsible for the product management process: roadmap, advocating for the customer in roadmap meetings, and mediating priorities to come to consensus.
• Solution Architect and/or Software Architect – responsible to design the tech stack, solution, and software framework for the product.
• Technical Team Lead – responsible to lead the engineering team in the development execution technical assessment of talent, sprint rhythm, input and output cost and quality, and ensuring proper process.
• Business analyst – responsible to convert product manager user stories into engineering ready user stories in an appropriate size with appropriate test criteria, dependencies and reminders of product wide requirements (where necessary, e.g., security).
• UX/UI – responsible for the user interaction design of the software, create and optimize the human interaction of the application.
• Developers focus on the “Middle Tier” (Business Logics) – responsible to handle the interaction with both the UI layer and database layer, handle the core business logics development.
• Web services and microservices – usually co-mingled with business logic, but at scale a separate function that focuses on the interactions between systems and use of containerization and microservices.
• Database Developer or DBA – responsible for the data schema design and database optimization, maintain the high performing relational database design, be the control person for data schema change.
• QA – responsible for full regression testing and identification of quality process leaks.
• Technical documentation – responsible for ensuring technical documentation is in place and accurate.
• Deployment – responsible for CI/CD deployment process.
• Security – responsible for security requirements and monitoring DevOps tools for security, performance, and vulnerabilities.
• Performance and dev-ops – responsible for monitoring and controlling dev-ops tools to provide proactive management of the user experience.
• Infrastructure – responsible for the infrastructure and environments the application(s) use.

Focus on the cost and quality of outputs, not inputs

We have seen so many teams fail by obsessing over the wrong metrics. Product development is a notoriously difficult thing to measure. As a result, most people default to the easy to count things like engineer salaries, hourly costs, code language licenses, etc. These are all inputs to the product development process and certainly can impact the output cost, but they don’t necessarily determine the output cost.

Input quality, rather than cost, has a much larger impact on output cost than the input cost. The true question for an organization is whether the output costs are in line or better than a benchmark. This simple statement is extremely difficult to scrutinize in practice.

We have witnessed our teams operating at four to five times the cost-normalized output of other organizations and inhouse engineers (i.e. our teams produce more for the same cost). This is not because our team members are geniuses (they are all extremely intelligent), but it rather due to the quality that they represent and our organizational ability to train, encourage, and resource them. When a founder focuses on the wrong metrics, the results will be disastrous.

Stability comes from consistency

As a practical rule, don’t change. First look at whether you are violating the rules outlined above. If so, rectify. A founder’s best technical bet is to improve the process around the team she has assembled already. Once accomplished, she can look for further improvements by inspecting the input quality (the engineering team, tech stack, dev tools, etc.)

At Golden Section, we created a product for enterprising founders to assess whether the company is optimized on output cost or not. We have seen improvements as significant as 85% cost reduction opportunities, but the average ends up around 40% improvements. This means most B2B SaaS founders with $500K in R&D spend could free up $200K of annual savings through an assessment. That benefit is a force multiplier for an early-stage company because it results in better capital efficiency (which investors love) and, simultaneously, more margin.

Conclusion

What founders build and how they build it are crucial to the long-term health of a software company. Product efficiency refers to cost with which the founder delivers the proper product to the customer culture they are serving. Rarely do founders focus on this measure. Most presentations and pitch decks have legion metrics covering sales and marketing efficiency.

These slides cover churn, acquisition cost, strategies, quotas, results by salesperson, etc. However, sales and marketing are usually a small amount of most early-stage P&Ls (10 to 30%). The lion share of early-stage capital needed is for product spend. And yet most decks have a simple, three row illustration of the ‘product roadmap’ despite the 70% slice of the P&L pie.

Product efficiency is a crucial measure of the health of the underlying company. It isn’t perverted by exogenous factors like exit price, and it is closely aligned with the decisions of management. The essays here speak to how to achieve product efficiency. Measuring it is simple. Just answer this question: what is the cost of building the proper product? And then: can the cost be reduced without negatively impacting the performance or timeline of the proper product? Putting those questions to data is a bit more difficult, but not impossible.

We hold a few concepts constant in pursuit of this data.

1. We expect the right founders will have the best perspective on the scope of the proper product compared to all other potential founders in the market.
2. That the proper product will find adoption among the intended customer culture.

If both conditions are met, then the proper product spend to achieve product efficiency is between 25% and 30% of run-rate revenue at scale (approximately $1M in ARR).

This means an incremental increase of $500k in run rate revenue during a quarter increases the product spend potential by $125k to $150k. This limiting factor, albeit somewhat arbitrarily applied, can constrain the software company in all the right ways and point the founder to what makes the ecosystem grow: Revenue.