One of the challenges of an early stage software start-up is whether to have a non-technical CEO who has a good set of relationships with prospective customers, or to have a CEO who really understands the technology and the art of software development. Like all tough questions the answer is “it depends.” Mostly it depends on how management savvy the CEO is regardless of their professional experience.

The following advice was created for a non-technical CEO who had very little management or executive experience on how to manage software development.

At the heart of management of any software start-up and software development and customer development is a quote from the Quality Guru W. Edwards Deming:

Expect what you inspect

“You can expect what you inspect. Dr. Deming emphasized the importance of measuring and testing to predict typical results. If a phase consists of inputs + process + outputs, all three are inspected to some extent. Problems with inputs are a major source of trouble, but the process using those inputs can also have problems. By inspecting the inputs and the process more, the outputs can be better predicted, and inspected less. Rather than use mass inspection of every output product, the output can be statistically sampled in a cause-effect relationship through the process.”

When you are doing a software start-up, there are multiple parallel processes that are going on simultaneously which is why what is called the “Waterfall Development Process” can never work for a V1 product.  Here is a list of some of the challenges along with proposed solutions or interventions:

• Unlike a physical object which has many physical constraints along with the constraints imposed by the science of physics, software has almost no constraints.  This aspect is one of the most wondrous aspects of software development and one of the most disastrous when trying to produce a product and meet deadlines.  There is always something else that you can add “easily” to the software and almost always a way for a software engineer to make the software better.
  • The successful executive must work tirelessly to impose appropriate constraints.  This is an art form in itself.
    • The kinds of constraints that can be imposed are:
      • Limit the amount of time to the next deliverable.
      • Limit the scope of what is to be built.
      • Limit the amount of resources applied to the development.
      • Focus on a single customer type for a single market in a single geography.
        • Focus on a single “bottleneck” or pain point (from Goldratt’s Theory of Constraints) that the customer currently has.
    • The best constraint I’ve found over the years is to limit the time by going to a daily demo.
      • That is, every day I want to see a 5-10 minute demonstration of the progress that was made the previous day.
      • In the process when I don’t see visible progress, I will at least get the reasons (generally in the form of excuses) as to why progress wasn’t made.  That is where I can help break through these roadblocks either by asking good follow up questions or by removing the roadblocks in some other way.
• When you set out to build a V1 product, most of the time you are setting out to envision and design something that hasn’t been done before.  Bringing this new thing into being means every day is an exercise in learning the implications of what the design means.  It’s like peeling an onion.   You very quickly run into the four boxes of knowing:
  • What you know
  • What you don’t know
  • What you don’t know you don’t know
  • What you know that is wrong

• The dynamics of the interaction of these four boxes are truly problematical:
  • As you learn more about what you are trying to do, you also expand exponentially that which you don’t know.
  • As the size of what you don’t know increases, so does the size of the box of what you don’t know you don’t know.
  • And as you keep learning more, you are also learning more things that are wrong.
• This expansion of knowledge is what I call the diverging (DIVERGE) of the problem space.
• So part of what you have to continually do because of the knowledge expansion (and thus scope expansion, not necessarily in terms of extra features or modules or lenses, but in terms of the amount of work and depth of a particular feature) is to CONVERGE and focus on what the customer (user, purchaser, influencer) really needs to solve their point of pain.  Which of course means that you need to be doing as much “customer development” work as software development (see “Agile is only half of what you need” for a very good discussion of this problem with pointers to several slide shows that are worth going through along with an article by Ash Maurya on “Customer Development“).
• But wait there is more.  Along with trying to understand WHAT to build, you are putting a team together to build it.  The challenges of hiring the key players while figuring out their strengths and weaknesses, and figuring out who else to hire, and figuring out the new hire’s strengths and weaknesses are a never ending talent challenge.  Not only do these early hires have to figure out how to work with each other to produce something but they (and you) are key to establishing what kind of culture the company is going to have (and that needs to be intentionally developed as well).
  • The biggest challenges are:
    • Making sure that the appropriate people are constantly collaborating with each other
    • Making sure that decisions are arrived at in a fast yet appropriate manner (more on this to come)
    • Making sure that decisions wherever possible are based on EVIDENCE (that is why I really like the mission statement that BlinkUX came up with – Evidence Based Design) rather than on interminable discussions and arguing over people’s opinions rather than demonstrated customer needs.
      • The more that you can focus the team on grounding their decisions on what really matters to the customer the better and quicker you will get through the V1 phase.  This is why I am so committed to Human Centered Design.
        • For example, there is no way that the Attenex Patterns User Interface and functionality and 10X+ productivity would have resulted from a designer or an information architect or an engineer devising the interface and declaring it good.  It came through the user research, user observation, prototype development and user testing of hundreds of design iterations.  Ultimately before we committed to any change, the performance increase had to be validated in usage.  Which meant we had to be very clear about who our users were and be able to test the “design improvements” on a regular basis.
        • It was quite painful when some of our best inspirations and designs not only didn’t increase productivity but dramatically decreased productivity.  These setbacks were a constant reminder to go back to paying deep attention to our customers (users, purchasers, and influencers).
• And more.  Customer Development – from the point of view of product development (not from the point of view of sales and marketing)
  • Finding the relevant customers for your chosen product domain and picking the right customers to listen to is another one of those start-up challenges.  It is particularly problematical because there are two competing priorities – get a sale (generate revenue as quickly as we can) and get a set of launch customers who have the problem that we are trying to solve for and will give us their most important asset – their time and attention.  It is very hard for a single person (CEO) to do both things at the same time.  The customer will always hear from your actions that one of the two goals is paramount (and for the CEO getting the sale is always paramount).
  • So for customer development you have to use resources that very clearly have an agenda of learning and helping and are just as clear that they don’t have an agenda of selling.  You have to separate out sales from customer development in the context of product development.  This is where companies like BlinkUX and IDEO come in because they are a neutral third party.  It is also where in house user researchers come in when you grow a little more as a company.  As much as I wanted to do both roles in the early days of Attenex, as long as I had the CEO title I was perceived as always being in a selling role.  It wasn’t till I switched roles to the CTO that I was really able to dig deeply into our customers’ needs by going in and observing companies like Pfizer, KPMG and FTI (when they were our biggest customer).

Yes, software start-ups are messy and many days it seems like you are taking two steps backward for every step forward.

My recommendation for dealing with the above in a way that keeps people out of opinion mode or whining mode or “it can’t be done because mode” is moving to a daily demo.  At a minimum, this lets you as the CEO always know where things are in a visceral way, not by trying to interpret status reports or email traffic.

Some attributes of the daily demo are:

• Phase I:
  • The total time for the daily demo and the discussion shouldn’t exceed 15 minutes.
    • You want to have the meeting at a standard time every day (usually first thing in the morning).
    • At the size of an early stage start-up, I would try and involve everybody in the company in the demo.
      • This is also a good way to get everyone to work at the same time (but I never said that).
      • However, if people are working staggered schedules don’t try and wait until the latest person comes in.  Get the meeting going early in the day, first thing if possible.  Do not ever do the daily demo at the end of the day.
    • Rotate who gives the demo to show case somebody’s work and to give everyone a chance to demo the whole product (another byproduct of the development of your talent).  It also gets people more comfortable with public speaking.  Often I would have engineers that were working in one part of the product demonstrate some other part of the product so they were constantly seeing the whole product in use.  Clearly they had to have advance notice to do that until they realized that I expected each of them to be able to always demonstrate the whole product.
    • The emphasis is on ACTUALLY DEMOING something.
      • This is not a time for anyone to lecture.
      • It is show and tell with the emphasis being on showing.
    • Questions during the demo should be “questions for understanding”.  That is while the “show” is going on be asking those questions that come from not understanding what you are seeing.  But don’t let the answer go on forever.  If the explanation is not clear in a minute or so, make a note to come back to that in a longer meeting, but press on to the next thing so that the 15 minutes doesn’t bog down.
    • Don’t let the daily demo become a surrogate design meeting.  That’s a separate meeting.
  • After the show part, then ask follow on questions like:
    • What did you expect to show today?  Basically you are checking for progress against plan.
    • What were the reasons for the differences between plan and what got accomplished?
      • What things didn’t get done and why?
• If there were extra things, what were they and how did they manage to get in?  You are looking for inadvertent scope creep.
  • As you start the daily demo, you want to get people into the habit of doing the above.
    • You should be positive at all times with liberal sprinkling of compliments for the cool stuff that appears.
    • This is not a meeting to place blame.  It is a meeting to celebrate the little accomplishments along the way.
    • This is your chance to observe how the development team is doing and how the software folks are relating to the product and marketing folks.  You want to observe any non-verbals like eye rolling or people not being able to look you in the eye and all those cues that lets you know that there is an elephant in the room somewhere.  These meetings are your early warning system.  However, these are not the meetings to do the problem solving in.  You want to problem solve in separate meetings.
    • If you get into a phase of the project where there doesn’t seem to be anything new to demo, don’t let the developers cancel the daily demo.  Continue to have the meetings and have them go through things you may not have fully understood in the past.  Pretty soon they will get the message that you are serious about seeing daily progress and you won’t take lame excuses.
    • Where possible you should hold to the daily demo even if  you are travelling or if someone is on vacation.  Make sure you have a license to Webex or a similar tool so that you can do remote demos.
  • Phase II:
    • Once people are in the habit of doing the daily software demo, then it is time to bring your marketing resources more to the fore by splitting the meeting into a daily demo of the software and a “daily demo” of the knowledge that is being gained about your customers.  This is where you move into evidence based design.
      • You want marketing to show a video or at the very least play audio tapes of some aspect of customers trying to do their job using your product.  This is where the user videos from a BlinkUX become so important.
      • You want to ground the development team in ACTUAL users, not made up personas or someone’s opinion.
      • This is not a place for the product marketing folks to pontificate or a place to get the developers to add a piece of functionality that a sales person thinks they need.  You want to focus on developing software that meets someone’s actual needs (evidence based design).
  • Phase III:
    • Once the group has gotten comfortable with showing the daily progress in the software development and the customer understanding, then it is time to move the daily demo into the final phase of sophistication – getting the development team to demo how they are doing automated testing and the many ways that they are trying to make the system fail proof.  Similarly, the software should be far enough along that you are able to do usability testing and so product marketing should now be adding in videos that show users trying to actually use the software and provide further evidence of what is required to build both a desirable and a usable product.

As with any software development effort, there are times when it becomes clear that you really need to understand something more deeply.  The thought tool that I’ve found most helpful grew out of Toyota, but I first came across it when studying W. Edwards Deming and the quality movement and six sigma.  Your role as CEO is to make sure that you are getting to the causes of any issues and not dealing with the symptoms. The Deming tool is the “Five Whys“:

“Systematically asking why an event occurs or a condition exists. The question ‘why?’ is applied to each response until the root cause of the event or condition is found. Sometimes the root cause is identified by the 2nd or 3rd “why.” In other situations it may take 6-7 ‘why’s’ to get to the root cause. Try to get to the 5th level without getting to an absurd level of detail.

“At the heart of this simple tool is the belief that real problem solving occurs when the cause, rather than the symptom, of the problem is addressed. This is often referred to as ‘drilling down’ to the heart of the problem. Dr. Kano refers to this ‘drilling down’ as ‘going an inch wide and a mile deep into a problem’ (real understanding leading to targeted solutions) rather than ‘going a mile wide and an inch deep into a problem’ (superficial understanding leading to shotgun solutions). At a more philosophical level, the 5 Why’s also demonstrate Dr. Deming’s principle that the real problem usually lies in the deeper system rather than in the performance of an individual who is working within that system.”

An example of the Five Whys:

Another thought tool that I find very helpful comes from Ed Lazowska, the Bill and Melinda Gates Professor of Computer Science at UW.  He found that if he tried to answer directly the question that a student or colleague asked him there was almost never a good result.  He realized that to provide a good answer he first had to ask “what is the misunderstanding that caused the question to be asked in the first place?”  Once he knew what the misunderstanding was he could provide an answer that led to understanding.

A wonderful book QBQ!  The Question Behind the Question: Practicing Personal Accountability at Work and In Life provides a comprehensive exploration of Ed’s insight.

The document on Decision Styles that is drawn from Bob Crosby’s Walking the Empowerment Tightrope: Balancing Management Authority & Employee Influence makes clear for those decisions which are important to be explicit about how the decision will be made and who will make it.  With most decisions it is clear.  But there are some decisions, like we are going to only focus on one persona or a single market or which concept search tool to use where it is important that as part of the evolving startup culture that you be explicit about how the decision will be made.  As a general rule you don’t want to have a culture where consensus is the primary decision tool.

For those decisions where you realize that you need to be explicit about the decision style, you should also start the formality of creating a decision record so that you can be working on continuous improvement of the quality of your decisions and which decision styles are working for your organization.  Russ Ackoff provides a quick and direct method for tracking decisions.

The article on Coaching for Performance provides some simple yet effective methods for working with your development talent. The article describes the Situational Leadership Model.

While this “advice” is a lot to absorb for the start-up CEO, by immersing the CEO in the ways to manage a software start-up there is a higher likelihood for success.

For a humorous look at the wonderful world of innovation and new ventures, checkout Fl!p and the gang at Fl!p Comics.