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.

This article is an extract from a case study we published recently published titled “A Founder’s Journey Through Building a B2B SaaS Company“, written by Dougal Cameron that shares some of our experiences building startups and journeying towards meaningful exits.