Posted on

Quantifying the ROI of secure coding trainings

Return on Investment for secure coding trainings
How do secure coding trainings influence real-world ROI? Delve into a transformative approach and its tangible business outcomes.

In the business domain, agility is essential. A transformative approach is to perceive employees as human capital rather than mere resources. The critical investment lies in focused training – especially when it comes to secure coding tranings. The returns are multifaceted, as it nurtures a workforce equipped to steer the organization toward progress. By valuing and developing the human element, organizations pave the way for sustainable growth and success.

By filling out this form you will be redirected towards the online article about how to measure your business outcomes from Secure coding trainings.

 

Posted on

System architecting for politicians

System architect

Over there, under the parasol, cap, sunglasses, beer, that must be our prime minister.
If I arrange another beer, can I join you?

Beer is welcome and if you don’t talk politics, you can join us.
System architect in politics
Illustration Rutte with Luud Engels

Deal! I am a political illiterate. I give a training here and can only talk a little about high-tech system architecting.
 

Sounds interesting! I’ve been on quite a few trade missions and I know the Netherlands plays a leading role there.

 
It certainly does! I’ve had the opportunity to work for companies that could predict which high-tech product they needed to have on the market in three years and put genius researchers and supremely capable engineers to work to reach that goal.

Precisely because it takes a considerable number of different areas of expertise to develop, manufacture and maintain such a high-tech product, a tangle of conflicting requirements arises from that multitude of disciplines. But the successful companies stand out because despite this tangle, they can agree on an approach and thus make the right decisions in a timely manner.
 

That must indeed be enormously complex. But fortunately, those bright minds and handy hands know which calculations and models to apply. In my work we also apply models, but they are more fodder for discussion than leading to consensus and correct decisions. With us, it’s more human work.

 
There may be more similarities there than you would think. All experts in high-tech are lords and masters in their fields and often take the stage to showcase exactly that: beta superiority.

On the one hand, you desperately need the expertise, models and calculations to keep those professionals innovating in their fields, digging deeper and deeper tunnels. And on the other hand, every new insight in a certain discipline is used as a weapon to beat the brains out of experts from other tunnels.

Islands arise, sometimes even camps, and the plague is that they all have a valid point.
 

Okay, okay, so it’s human work too. But you said just now that they do come to an agreement. So how do they do that?

 
It’s all about system architecting. They reach working agreements – you can call it an approach – in which the various disciplines provide each other with insight into where, in essence, the contradiction is manifesting itself and for which parameters a balanced solution must be found. So this is not about negotiating or trying to reach consensus, but making jointly weighted choices. Once they all have an overview and agree on the entire system, these bright minds subordinate their own tunnel wisdom to, say, the higher good.

Check out the Sysarch training

 

Nice that that’s how it works in high-tech, but how different it is with us. No doubt you have seen debates where people are too busy proclaiming their own party truth and unwilling to listen to each other, let alone understand each other. That system architecting doesn’t work with us.

 
I’m going to play devil’s advocate; those debates do not have the common purpose that does prevail within successful companies. In the debates, the system goal is conspicuous by its absence.
 

No, it can’t be because of that. For example, we have set a very clear goal for nitrogen reduction: half less by 2030. So how concrete do you want the goal to be? 

 
Here you touch on a basic error. You see, that reduction is not a system goal. This is exactly where constructive companies differ from politics. Let me explain.

The system goal will include terms such as food quantity, food quality, sustainable operations and conservation of environment. However, no system has ever been developed with the goal of reducing nitrogen, which is exactly why many protest as soon as you do set that as a goal. Don’t get me wrong, I’m no climate wimp. I see the excess nitrogen deposition as a negative effect that needs to be fixed.

I am pretty sure that farmers, citizens and businesses subscribe to the system goal of producing food in a sustainable way in the Netherlands. If you had invited them to keep heading towards that system goal while the nitrogen surplus needs to be repaired, you would have got cooperative thinkers instead of counter-thinkers. The system goal always involves a desired effect, and most people therefore want to participate in it.
 

I see your point. So the Netherlands can be governed by system architects?

 
Govern not, but even politicians would benefit from practices and methods such as those within system architecting:

''Proclaiming system goals results in solution supporters.''

''Proclaiming solutions results in aimless opponents.''

 

So we messed up?

 
In this line of approach, certainly yes! However, some things have also been messed up in high-tech, and misses will continue, but every mistake is an opportunity to improve. How else do you think systems architecting came about?
 

By the way, you wouldn’t be talking about politics!

 
I didn’t, we just talked about decision making.
 

Posted on

Trend 4: The W model

System requirements engineering trainer
High Tech Institute trainer Cees Michielsen highlights a handful of trends in the field of system requirements engineering. For High Tech Institute, he provides the 2-day training ‘System requirements engineering‘ several times a year.

 

In high tech, people often refer to the V model when they talk about the process from initial ideas to product implementation when it comes to system requirements engineering. This model starts with a functional breakdown, the left leg of the V. In practice, however, you can’t include all requirements in the traditional functional breakdown. Typical examples are the physical properties of products – mass, volume, that sort of information.

It would be wise to expand the V model to what I call the W model. This model starts with two parallel trajectories in the left leg: the functional and the physical flow. Both accommodate separate system aspects: the functional flow is primarily concerned with ensuring that the required functionality is implemented, while the physical flow ensures that the physical aspects are budgeted down to the relevant system elements.

The two left legs join forces at the so-called ‘building block’ level, where the elements of a functional system, eg the braking system of a car, are specified and designed according to their requirements. These elements have both functional and physical characteristics. In the braking system example, one of the building blocks is the brake pedal, which is specified by functional requirements that make clear what the pedal is supposed to do and by physical requirements that specify the constraints concerning the pedal mass, the allowed design envelope, material and more.

Building blocks are defined at the level at which specific functionality is specified, designed and implemented. This doesn’t mean that they’re always single parts; they can be quite complex, like the motor of an electrical car. It is important, however, that they always have two ‘parents’: a functional parent (to ensure that the braking system can rely on the functionality of the brake pedal) and a physical parent (to ensure that the pedal fits the intended location and that it meets the volume restrictions in the driver’s cabin, as well as other interfaces).

The use of building blocks prevents models from becoming too detailed. At the same time, it enables practical product management, especially for complex systems, both within the product design and within the manufacturing domain. For an average passenger car, around 400 building blocks are defined; the latest ASML machines have around 2,000.

Once released, the building block design is virtually integrated into the functional and the physical structure, both all the way up to the system level. The purpose is to demonstrate that the design satisfies the requirements at each level, functional as well as physical. These are the two upward legs that form the middle part of the W model.

This approach has several advantages. It brings clear responsibilities at the system level for both functional and physical requirements throughout the system’s life cycle. It enables unambiguous budgeting of physical aspects such as mass and volume downstream. It facilitates the early detection of possible integration issues (“it doesn’t fit, product not balanced, too heavy, interfaces not adhered to”) – during the design phase, before regular product integration. It makes the responsibilities for the ‘functioning’ of the elements explicit – the team designing the braking system must demonstrate that it works according to the requirements; there are no excuses to wait until the whole product is integrated.

It’s good to realize that the average functional subsystem, like a braking system or a level sensor, doesn’t appear on a manufacturing bill of materials. You don’t order a braking system, you order its building blocks. This means that, in the manufacturing or logistic environment, it’s difficult (if not impossible) to say what function a component on the factory floor or even in the end product fulfills. If, however, you would follow the logic as explained in the W model, it would be a piece of cake as the implementation of the building block also traces back to its functional parent(s).

 

 

Posted on

Trend 3: Traceability

System requirements engineering trainer
High Tech Institute trainer Cees Michielsen highlights a handful of trends in the field of system requirements engineering. For High Tech Institute, he provides the 2-day training ‘System requirements engineering‘ several times a year.

 

The principle idea of traceable requirements is really cool: being able to both top-down follow a requirement from its creation to its implementation and bottom-up from its implementation to its origin. Most textbooks give good-looking diagrams and tables showing how requirements are linked to other requirements and test cases. Unfortunately, these diagrams and tables have little to do with everyday practice.
 

System requirements follow systems engineering principles. Let’s take the example of a waterway lock. At the system level, there will be a requirement stating that the lock shall enable boats to travel upstream and downstream through the canal. How to break this down if we haven’t yet decided how to solve the problem, or in requirements terminology: how to satisfy this requirement?
 

In practice, we see a large variety of solutions, from the magnificent Scottish Falkirk Wheel (a true boat lift) to the Dutch locks at Eefde. Two completely different solutions for the same problem. So, what to do with the traceability of our system requirement?
 

In the case of Eefde, a lock consists of two gates and a chamber. Each component has its own capabilities but none of the components can satisfy the system requirement on its own. That’s why we need the design decisions as an anchor point in the requirements flow (top-down, requirement to design decision to requirement) and in the trace-back (bottom-up). Through the design, we understand that when we open one of the gates, the water level in the chamber will become equal to the level at the opened gate. Subsequently, the boats can move into the chamber through the open gate. Therefore, one of the so-called derived requirements for the gate subsystem is that it can be opened and closed.

[Courseinstructor heading=”‘Why do we have this requirement and why does it have this value?'”

The questions that we need to answer and for which we need the bottom-up traces are: why do we have this requirement and why does it have this value? The answers can only be found through traces from requirements at the subsystem level to the design decisions one level up, in our case the system level of the waterway lock.
 

System engineers also need to deal with resource budgets, like mass, volume, energy, operational space and material cost. All of these enter the requirements specification at the system level as individual requirements, but they’re never passed on to the subsystems without analyzing them in coherence, creating a design that takes all pros and cons into consideration and finally deciding on which solution best satisfies these system requirements.
 

In reality, there are many dependencies between, in this case, resource property requirements. Especially in the automotive industry, mass and material cost are two vehicle properties that are strongly intertwined. At the system level, the overall mass budget is established: the vehicle shall weigh less than 1,500 kg, and so is the material cost budget: the total cost of materials shall not exceed 7,000 euros. Then, in case tough decisions must be made, a priority is determined, eg less weight is more important than material cost.
 

The design will try to find a solution for this and allocates budgets for mass and material cost, balancing these requirements and, at the same time, assuming certain capabilities of the subsystems that contribute to these budgets. Finally, when a decision is made for a solution, parts of the mass and material cost budgets are allocated to the subsystems.
 

If you’re responsible for one of these subsystems and were given a mass budget of 100 kg, where would you look for answers to the questions: why do I have a mass budget and why is it 100 kg?

Posted on

Trend 2: Good quality requirements

System requirements engineering trainer
High Tech Institute trainer Cees Michielsen highlights a handful of trends in the field of system requirements engineering. For High Tech Institute, he provides the 2-day training ‘System requirements engineering‘ several times a year.

 

Can we objectively say that a requirement is of good quality? What would be the measure for good? Is there something like ‘good enough’? Most of the answers to these questions can be found in the work of Philip Crosby, William Edwards Deming and Joseph Juran. These three quality gurus are no longer among us, but their ideas remain a great source of inspiration.

As requirements are the result of a requirements engineering process, it seems logical to check if a requirement meets the goals of the process. Firstly, the stakeholder needs have been established, and secondly, a correct and complete transition of the stakeholder needs is ensured up to the decomposition level where requirements can be implemented into hardware or software components. I will focus here on the second goal.

A distinction is made between intrinsic and extrinsic requirement quality. Intrinsic means that the requirement’s quality is determined by the way it’s documented or presented to the reader – the requirement’s syntax. This can be either purely textual or embellished with images, tables and more. The check can be done, in theory, by persons or applications lacking subject matter knowledge. They don’t need to understand what the requirement is about but rather see if it violates rules for writing requirements. Deming speaks of “pride of workmanship” and “well-crafted requirements.” In the course of the last 10-15 years, software tools to support these quality checks have become more and more advanced. In tools such as QVScribe, checklists like the Writing Requirements guideline of the International Council on Systems Engineering (Incose) are completely embedded and intrinsic quality checks are fully automated (including various requirements templates like EARS and IREB).

Note that the intrinsic quality only covers one-third of the total requirements quality. But the intrinsic quality checks do have value. If they’re carried out and corrections are made before the requirement is reviewed by subject matter experts and relevant stakeholders, these tools can save time and indeed be helpful to improve the quality of requirements.

But tools won’t help you determine if your requirement is meaningful to the intended audience. This is where the extrinsic quality of requirements comes in. It applies in two directions: back to the stakeholders who requested a specific feature of the product to be developed or a product characteristic or behavior (the source audience), and forward to the receivers of the requirement (the target audience).

Let’s consider the following requirement: “The responsiveness of the system shall be less than or equal to 0.5 ms.” This requirement will most likely pass the automated quality checks with flying colors. In practice, it’s often formulated as: “System responsiveness: ≤ 0.5 ms.” Would you say these requirements are of equal quality? From a syntactical perspective, the first will give a higher score as it contains a directive, but it isn’t until we ask the relevant stakeholders that we have some idea whether the intended meaning was translated correctly.

[Courseinstructor heading=”‘equirements engineers need to have their requirements checked and judged.'”

Quality is conformance to requirements, says Crosby. Did we, as requirements engineers or business analysts, correctly translate the stakeholder’s need into a system requirement? This can only be answered by the stakeholders who posed the original need. So requirements engineers need to have their requirements checked and judged – an activity that’s perceived as difficult.

Suppose the customer says that the engineer hasn’t understood the request? Or that he completely missed the point? Such feedback isn’t always pleasant and that causes a requirements engineer to avoid these confrontations. He often takes the safe route by contacting someone from the project to represent the customer or stakeholder.

That’s not a smart attitude. We want to make sure we’ve understood the stakeholder’s needs and translated them correctly and completely into requirements. Therefore, there’s no other way than to ask these difficult questions directly.

Quality is fitness for purpose, says Juran. Requirements must contain sufficient information and detail for designers to come up with solutions. The requirements are expected to be quantified to enable testers to verify and validate their successful implementation. In short, they must be clear, unambiguous, meaningful and have sufficient detail for those who receive the requirement as input for their work.

I’ve seen cases where no requirement documentation existed between an OEM and one of its component suppliers. Just a verbal agreement. Although this may seem an unacceptable situation in some cultures, the goals of the requirements engineering process were met. The supplier has been delivering the component with constant quality to the satisfaction of the customer for over twelve years now.

What would you do in situations like these? How do you see the quality of requirements in your company? How would you handle stakeholder needs like “I want the next version of the car to be more energy-efficient”? I’d be happy to hear from you, to learn and pass it on.

Posted on

Trend 1: Getting you system requirements complete

System requirements engineering trainer
High Tech Institute trainer Cees Michielsen highlights a handful of trends in the field of system requirements engineering. For High Tech Institute, he provides the 2-day training ‘System requirements engineering‘ several times a year.

 

A question that pops up in almost all of my system requirements engineering classrooms is: how can we make sure that our requirements specification is complete? This is a valid question. Missing requirements usually means missing capabilities of the products we’re developing. It will have consequences for the success of those products. Either users of a product are disappointed because they expected something that’s not delivered or the product isn’t competitive enough compared to others with similar functionality.

 

Practice shows that requirements specifications are seldom complete. It’s just very difficult to make and keep them complete. Fortunately, over the past decades, we’ve learned some techniques and methods that can help us in our pursuit of completeness.

'Templates and checklists really work.'

First of all, templates and checklists really work. Originating from the early days of engineering, they help us not to forget the obvious requirements. Today, there’s help abound. The internet is littered with checklists especially focused on requirements.

 
You’ll also need to do some digging yourself: find all stakeholders with a potential impact on the product’s success. Forgetting stakeholders often means that you also won’t capture their needs and expectations of the product’s capabilities. That’s a recipe for failure. Of course, you’ll have to question and challenge your stakeholders to find out what their real needs are. It also helps to make these needs explicit. Don’t invite the fire brigade when you commission a newly-built tunnel just to find out that you may have missed some essential safety measures. You need to involve the firefighters in the early stages during requirements gathering.

 
Make sure to look at the product-to-be-built from different perspectives. View it through the eyes of actual users, owners and investors. Include stakeholders who also experience the negative effects. These perspectives are sometimes best described in a concept of operations, user stories, use cases and scenarios.

 
Realize that the requirements elicitation step (where you identify stakeholders and their needs) takes place at every decomposition level of your product architecture for every system element! At each level, you’ll find new stakeholders specific to that system element at that level. Think of software coding standards in a multidisciplinary product.

 
Analyze the needs in a structured manner. This means differentiating between the main function of a product and its subfunctions, between a function, its properties and its design constraints. In the end, you need to find a balance between performance and resource property requirements for functions.

 
If we take a passenger car as an example and say that “transporting people” is its main function, we need to express and quantify how well we need to transport people: how comfortable, how reliable, how many people, how safe? These are examples of performance properties (or qualities) of a function. They’re balanced with the resource properties, like: how much energy may this performance cost, how much material cost, how much noise? Whereas the analysis identifies the functions, properties and constraints, the requirements specification step quantifies the properties.

 
This is part of the structured requirements analysis method and is one of the effective ways to discover the so-called emerging properties – properties that weren’t requested by any stakeholder but represent a specific product aspect resulting from choices made in the design. For example, choosing a combustion engine gives noise and toxic gas emissions as emerging properties. Some of these emerging properties may suddenly become very important after having been disregarded for a long time, as we’ve seen for NOx emission. Point is that once a design choice has been made, you should look at the consequences (good, bad and ugly) to see if new requirements should be created to manage the emerging properties.

 
Over the years, the names of the product development departments have changed quite a bit, especially the groups responsible for writing the requirements at the product (or system) level. From product definition, via systems engineering, we now see groups (sometimes departments) named in such a way that it’s very clear what they stand for, like “Product Properties and Customer Functions.” Similarly, the title of Porsche’s Hansjörg Maier says it all: “Leiter Produkt-Eigenschaften und Kunden-Funktionen.” This gives a tremendous focus on what’s key for the product, both its functionality and its properties, and what makes the product stand out from the competition.

Posted on

Leadership skills for architects challenge

Leadership skills challenge

As a technical leader, you need to steer both the project and the company in the right direction. To do that, you must be able to convince stakeholders, influence without authority and exhibit personal leadership.

What would you say to improve the situation and cooperation? Take a look at 5 different situations and tell us how you would respond. You will get personal feedback from trainer Jaco Friedrich and you might win a Tiny Tony’s distribution box.

 

START CHALLENGE
Posted on

Entrepreneur lesson #3: Customer interest is no evidence of buying intent

One of the largest frustrations of startups trying to work with big enterprises is the enormous amount of false positives. Many startup founders have fallen into the trap of getting promising feedback from individuals from large companies and believe that they’re close to getting a deal in place. This positive feedback may continue for a long time, but the actual contract never materializes. There are many reasons why this happens, not the least that orchestrating an actual contract with an outside party is quite an uphill battle in many companies, but it’s a good reminder to make sure that, as a startup founder, you don’t allow your team to chase ghosts.

With some of the researchers I worked with I’ve experienced something similar. Some research results received enormous interest from companies, large and small, on industrial conferences to the point that we had hundreds of people in presentations and tons of positive feedback. When we then decided to commercialize the technology, the initial interest vaporized quickly and it turned out that although people were interested in the idea behind the technology, there was no willingness to actually buy the solution.

One major factor in all this is the notion of socially desirable behavior. When a startup founder talks to a potential customer, this customer tends to provide feedback along the lines of what the founder would like to hear. This is normal human behavior and one of the reasons why societies work well. If we always told everyone we meet exactly what we thought of them, there would be significantly higher levels of conflict and strife in the world. As a founder, though, you need to be cognizant of this and seek to ask questions that minimize the need for others to tell you what they think you’d like to hear.

Within the startup space, there tend to be two schools of thought. The first group is looking to get people to use their offering and to get to a large user base before thinking about monetizing. This group has a point in that you’re looking to minimize friction for adopting the offering, and paying for something that you don’t even know will help you is a significant hurdle for most. Also, if the offering is monetized indirectly, eg through advertising, in-app purchasing or freemium, the focus on growing the user base may well be the best way forward. The challenge is then often to fund the business until the monetization part starts to work.

The second group believes that buying intent and willingness to pay is an integral part of the validation of an innovative offering. That means that during the first stages of even talking to customers about the offering that you haven’t even built yet, you explicitly bring up price and payment terms to get feedback on that, too. Of course, what customers say can very well be, and often is, different from what they do, but their verbal feedback is at least an early signal. When there’s enough positive feedback and you decide to build an MVP, it’s then possible to test customers’ willingness to actually buy the service by offering the MVP for a fee.

'Verify buying intent as early as possible and based on actual customer behavior'

Typically, I recommend the startups I work with to focus on the second model, ie verify buying intent as early as possible and, where feasible, based on actual customer behavior. Especially with novel business models in established markets, this may not be the right answer, though. Several startups are exploring models where customers pay with their data. That’s fine, but it does require that you have a solid hypothesis on how you can use that data to monetize elsewhere. And, in general, the more complicated the business model and the larger the number of stakeholders, the harder it will be to build a viable business as more things can go wrong and more hypotheses about your business need to be true.

In the end, we all have limited resources and the goal for any startup should be to test the underlying hypotheses of the business as early and as cheaply as possible to minimize wasting time and money on things that don’t pan out. Killing an idea and pulling the plug is incredibly hard and figuring out when to do so is even harder, but the risk is that you keep wasting resources on a business that isn’t going anywhere. The opportunity cost of that can be enormous as it keeps you from moving on to a next business or pivot that turns out to be more promising.

For a variety of reasons, interest from potential customers is far from the same as buying intent. As an entrepreneur or an intrapreneur, confirming willingness to pay by the stakeholder group that you’re looking to monetize, ie the customer, is critical and generally best done as early as possible. This is advice that’s easily complicated by all kinds of realities surrounding the business, ranging from slow-moving B2B sales cycles to multi-sided markets, but ignoring the reality of a for-profit enterprise (that you need to make money to create a profit) is a surefire way to fail. As the famous business professor, Peter Drucker, said: the purpose of a business is to create a customer!

Posted on

Entrepreneur lesson #2: Build it and they’ll come is setting yourself up to fail

Entrepreneurs are, by definition, irrational optimists who have strong confidence in what they’re pursuing. Even if all of us can have bouts of doubt, entrepreneurs are managing these doubts and focus on executing on their convictions. The risk, however, is that you start to believe in your own convictions so hard that you fail to be responsive to outside input.

One of the hardest challenges in startups is the balance between building based on your conviction on what the world needs or is going to need and incorporating feedback from customers and the market. Only listening to what customers say will result in too small a delta compared to existing products. And if you don’t offer a 10x improvement in some dimension, there typically is too little incentive for potential customers to go through the pain of switching from whatever they’re using today.

On the other hand, ignoring input from the market and blindly building what you believe is needed is a sure way to fail. People aren’t going to buy from you because of the compelling story you tell. They only buy from you because your offering provides some significant benefit over alternative solutions. Entrepreneurs are by necessity rule breakers and, by and large, tend to ignore market input longer than what’s good for the business.

A complicating factor is that many startups aim to exploit some technology, standard, trend or regulation that has the potential to disrupt an existing business ecosystem. The disruption is often in the early stages, as others will already have jumped on the opportunity, and the startup is basically betting the farm on hitting the market with a sufficiently compelling offering right when the disruption is gaining momentum. That means that collecting relevant feedback from the market is impossible as there is no market yet.

This explains why, according to some research, the primary success factor of startups is timing: being at the right place at the right time. Not very satisfactory for people who try to develop predictable and repeatable patterns for startup formation but a reality that we all have to contend with. Whenever I ask entrepreneurs why some idea or startup failed, in a significant number of cases it’s some event or development completely outside the scope of the startup’s control that knocked the whole company off course.

In my experience, though, the common factor in all companies I was involved in that didn’t do so well is lack of sales. Sales cures all ails, the saying goes, and it really is the case. As Peter Drucker famously said, the purpose of a company is to create a customer. Failure to do so can of course lie in an insufficiently compelling offering, but as often, it’s failing to find the right customer for what you have to offer. The idea that many engineers have, ie that a good product sells itself, isn’t true at all and most certainly false for startups.

'Your initial customers may not at all be the right ones'

My main learning in this context is to make happy customers. Many companies fall into the trap of making customers happy. There’s an important distinction. In the latter case, you focus on the customers you have and try to make them happy. The problem is that your initial customers may not at all be the right ones. For instance, one company I worked with managed to secure a few very large customers who were then continuing to demand such amounts of dedicated attention that this consumed all R&D resources. As a consequence, the company was unable to expand to new clientele but had grown dependent on the revenue these few large customers brought in.

Making happy customers starts with defining the profile of your ideal customer. You then continue to sell to the potential customers fitting your profile. Any customer who, over time, proves to not be the right match for you, you may decide to fire. Or, at least, you don’t give in to requests that deviate you from the customer profile you’re looking to serve.

Being clear on the customer profile you’re looking to serve also helps in aiming to time a market disruption. Although most consider a disruption to be instantaneous, for those on the inside it’s clear that it’s a slow process with a few companies getting into the transition early and the majority following at a later point in time. Finding these early movers, making them your customers and then together with them experimenting your way through the disruption is one of the safest ways forward for a startup; it gives early feedback on the suitability of your offering and gets you ready for when the tornado hits, as Geoffrey Moore calls it.

Startups need to carefully balance a solid belief and confidence in the core idea behind the company and incorporating feedback from the market. Straying too far to either side is a recipe for failure. The best approach is to “make happy customers” rather than making customers happy. That allows you to find those early adopters and work with them. It still leaves you with the challenge of scaling to serve the larger market, but that’s a concern for a later time. If you don’t survive now, you’ll never have the challenge of scaling, so why bother worrying about that now?

 

Posted on

Entrepreneur lesson #1: Too much early funding kills a startup

My grandparents from my maternal side were farmers and had cows. Their mature milking cows were put in fields with lots of lush grass and could eat what they wanted. The young cows that hadn’t yet been bred were put in the fields that had already been cleaned out by the milking cows or on poor pastures. My initial belief was that this was a cost-saving measure as the young cows didn’t give milk yet, but that was wrong. The real reason was that feeding young cows just enough so that they don’t go hungry but stay lean causes them to become bigger cows when they grow up, with a stronger frame and better milk production.

The funny thing is that the same is true for startups. In my experience, having too much funding during the early stages of a startup is counterproductive and may well cause the venture to fail. Most founders I talk to about this shake their heads in disbelief as they feel they’re constantly scraping by, closing deals by bending over backward for customers and permanently walking around with a feeling that they’re deviating from the company’s original mission.

Also the fear of running out of money and disappointing the friends and family who invested their hard-earned savings as well as the employees who are depending on you for their paycheck is real and results in existential angst in anyone with a bone of empathy in their body. Nobody wants to be a failure and for all the noise of the “celebrate your failures” movement, everyone I know prefers to celebrate other people’s failures.

The point is, however, that in all your jockeying for closing deals with customers, being responsive to their needs and wishes, adjusting your vision to the feedback you’re receiving, you’re navigating the design space of your offering and gradually nailing the content and functionality you need to have to build a successful company.

When a startup has too much funding in the early stages, the founders and employees tend to focus internally, build products based on their own opinions and ignore customer input. Because of this, the constant interaction with the market doesn’t result in a constant adjustment to customer input. Instead, the customer feedback is explained away and often translated into features that will be added to the offering later after we’ve built what we’re certain the customer needs.

Another consequence is that the company rapidly builds up to a burn rate that vastly outpaces the revenue coming in, causing a perpetual dependency on raising more money. And, believe it or not, raising money is actually addictive. In lieu of market success, it’s incredibly satisfying to at least have found investors who believe in your dream and are willing to carry the company forward for another couple of months. The problem is, of course, that raising money only confirms your storytelling ability, not the viability of the business. Also, all the time you’re busy raising money, you’re not building the business with customers.

'Startups only really benefit from large amounts of funding after they’ve nailed the offering'

There’s a time when startups really benefit from large amounts of funding, which is after they’ve nailed the offering to the market and the investment goes to executing a scaling strategy that allows for regional expansion as well as expansion to serve multiple industries. However, this should happen after you’ve nailed the offering and you have the revenue to prove it.

In the end, the balance for investors is to give startups enough funding so that they don’t have to raise money all the time and the founders can focus on building the business. And, at the same time, not so much that the company stops feeling the dread of possible extinction (staring into the abyss, as Elon Musk calls it), which causes the focus on adjusting yourself to customer needs rather than a fictive, unconfirmed belief about the market. As a founder, most of what you believe about your market, customers and offering is wrong, but you don’t know which part. Constant interaction with the market causes you to kill your darlings to get to a viable product and company that manages to become cash flow positive and, preferably, grow like a weed once you’ve nailed it. But for that, you need to stay lean, just like my grandparents’ cows.