Startup Execution

The Seven Sacred Abilities

Technology is complex. In the world of corporate Information Technology (IT), thousands of products compete for mindshare. Many startups with enterprise solutions struggle to position their value against larger, established IT vendors. In order to compete, startups should leverage a structured process for evaluating and selecting among multiple options the solution that best fits the needs of your prospective customers.

The Method to the Madness

In my experience, most companies take an unstructured approach to choosing an IT solution. At best, companies looking for an enterprise solution may conduct a brainstorming session to compile a long list of requirements that eventually feeds an RFP. Companies then evaluate vendor responses, apply some score to each line item requirement of the RFP, and then attempt to select a solution.

Though this process provides some structure, I feel it is still suboptimal. Buyers tend to struggle to digest vendor responses to fifty or more individual line item requirements. It becomes difficult to evaluate and compare solutions because customers struggle to see the forest through the trees. In addition, any attempts to apply different weights to individual line item requirements complicates an already complex problem.

Back when I worked as a management consultant, I developed a process that I whimsically called the Seven Sacred Abilities to provide a methodology and a framework to address some of these issues. The process involves grouping individual requirements into seven higher-level, prioritized categories as depicted below.

Each ability is further defined below:

  • Affordability: Affordability assesses the initial capital and on-going operational expenses to acquire and operate the solution. This data provides the cost component of a return on investment analysis.
  • Availability: Availability deals with system uptime and fault management requirements. Considerations such as management of scheduled and unscheduled downtime, mean time between failure, mean time to recovery, recovery time objective, recovery point objective, fault detection, fault monitoring, fault correlation, and fault handling all contribute to fault transparency and system resilience.
  • Capability: Capability considers the product architecture, features, benefits and compliance with industry standards or regulatory requirements. A large portion of the requirements usually focus on product capabilities.
  • Interoperability: Interoperability takes into account the solution’s ease of evolution, integration, extensibility and flexibility. With the current market trend towards cloud native architectures, microservices, API integration, and automation/orchestration, interoperability often becomes imperative to modern technical solutions.
  • Manageability: Manageability evaluates the solution’s overall  operational capabilities, including building blocks such as transaction-level metrics that feed system-level analytics, single console management, support for standard management protocols and the ability to integrate with distributed systems management frameworks.
  • Scalability: Scalability evaluates the product’s handling of high transaction volumes, concurrent users, overall throughput, speed, latency, data size, and the ability to grow via smaller stepwise upgrades versus large-scale investments.
  • Vulnerability: Vulnerability considers the overall security infrastructure, product hardening, industry certifications, and its fit within a multi-layer, integrated defense system.

I usually recommend customers prioritize these seven abilities using the following scale:

  • High: the most important abilities that will generally serve as the key selection criteria. Solutions that score well on these key abilities will usually rise to the top of the product selection process. In general, there should be two to four abilities classified “high” — any more than four usually suggests a buyer with unrealistic expectations and an inability to prioritize.
  • Medium: the abilities that every solution must satisfy, but generally won’t serve as key differentiators during the product selection process. Solutions with higher scores on these “table stakes” abilities rarely influence the product selection process. In general, there should be two to three abilities classified “medium”.
  • Low: the abilities that do not factor into the product selection process. The only exception would be any solution that fails to meet the criteria in some extraordinary way. Good, average, or below average scores don’t affect the product selection, but a terrible score may eliminate a product from consideration. In general, there should be one to three abilities classified “low”.

Once these seven abilities are prioritized, individual requirements are then compiled and categorized. Vendor responses to line item requirements can then be streamlined and more efficiently evaluated.

Quantitative or Qualitative?

Many buyers use a quantitative approach to weight and score individual requirements. The buyer creates a spreadsheet with formulas that calculate a final numeric score that supposedly results in a winning product selection. Sadly, problems plague this seemingly objective process, often resulting in a product scoring well due to mathematical coincidence rather than its actual fit to the requirements.

One major problem is the sensitivity of this mathematical model based on the underlying assumptions. A small change to the weight of a certain requirement can result in a completely different score for the short-listed products, as illustrated in the example below:

Example of Problems with Quantitative Scoring for Product Selection

Another problem is the weights chosen for each requirement and how they semantically compare to each other. In Scenario 1 from the example above, Requirement 1 is weighted 30%, while Requirement 5 is weighted 10%. But is Requirement 1 really exactly 300% more important than Requirement 5? In Scenario 2, Requirement 1 is 167% more important than Requirement 5 (25% vs. 15%). It’s difficult to say which scenario more accurately captures the true business importance of the individual requirements.

Because of the difficulty of building a quantitative scoring model that accurately reflects the business need, I recommend a qualitative scoring system. I typically use the following (somewhat subjective) grading scale:

  1. Excellent
  2. Very Good
  3. Good
  4. Fair
  5. Poor
  6. Unacceptable

I recommend building a table that summarizes your findings for an executive audience. Annotate the grades with several salient bullet points supporting your score. In the (slightly dated) example below of a bake-off of Cisco home office firewalls, the four high priority abilities are presented, along with grades and details supporting the grade.

Sample Executive Summary of Seven Sacred Abilities Product Selection Process

Building this one-page executive summary helps your customer present their findings and overall recommendation to their internal decision makers. Capturing several bullet points for each grade helps your customer respond to questions that arise during the discussion.

The Value of Goodwill

Besides the inherent value of using a framework for product selection, startups instill confidence when they follow structured processes — it says you are a veteran that has done this before. You also build goodwill when you provide your customers the process and tools to make the right decisions. In addition, your leadership during the sales cycle commands respect and elevates you to trusted advisor status. These intangibles solidify your relationship with the customer, which can tip the scales in your favor should your solution be considered roughly equal to that proposed by another vendor.

As any startup veteran will testify, winning customers is critical to your success. Maximize your sales effectiveness by leveraging the Seven Sacred Abilities to create a clear, logical, and effective process for competitive product sales.

Startup Execution

Interviewing – The Unheralded Startup Skill

Java. HTML5. MongoDB. Agile/Scrum. REST/JSON. Kubernetes. AWS. Product management. GAAP/financial accounting. Channel development. Interviewing.

Wait. Interviewing?!? Yes, interviewing skills!

Startups hunger for talent. A company’s ability to source and hire skilled employees determines its ability to grow. A quick search on any job board produces long lists of openings for web developers, DevOps engineers, cloud architects, mobile app developers, product managers, sales engineers, business development managers, accountants, and more. Building a robust hiring engine is an often overlooked but essential part of growing a startup.

How Borderline Employees Get Hired

A growing startup devotes a significant amount of time and effort to interviewing candidates to fill open positions. However, very few companies spend any time to establishing a structured interview methodology. In the rush to get back to their primary job of writing code, chasing a deal, or closing the books, startups assume employees know how to interview prospective employees. The hiring team rarely does any advance planning to prepare for candidates coming onsite for an interview. Interviewers are left with no guidance and no structure. The interview may cover overlapping topics and/or miss several key topics, resulting in a disjointed and disorganized process. One of a startup’s most important operational decisions is left to an unstructured and subjective sense of whether the interviewers generally liked the candidate. This mistake allows a higher percentage of borderline candidates to join the team.

Borderline employees dilute the effectiveness and productivity of the entire team. Senior employees invest one of the company’s most precious assets – time – into training the new employee and getting them up to speed. Team leads, managers, and peers spend multiple man months on a new hire, only to be disappointed in the borderline employee’s output. Companies can minimize these headaches by adopting the simple, structured interview guidelines below.

Behavioral >> Situational

First, every person on the interview team must understand how to conduct a behavioral instead of a situational interview. Many great articles are available that dig into the definition of these terms and provide detailed explanations of why behavioral questions are better than situational. In short, behavioral interviewing asks the candidate to describe how they handled a past experience. In contrast, situational interviewing asks the candidate to make a choice among several options presented.

Behavioral interviews are built on the premise that past history is the best predictor of future behavior. A behavioral question or request tends to start with “Tell me about a time where you (faced a certain problem)”. A situational question tends to resemble “What would you do if you (had to choose between option A and option B)?” Behavioral questions tend to extract a better picture of a candidate’s ability to execute. A person who is good at interviewing will often be able to guess what the situational question is driving at and will give you the response you wanted to hear. For example, “Tell me about a time where you faced an unreasonable deadline” will provide good insight into how the candidate handles pressure. In contrast, “What would you do if you had to work late to meet a deadline?” usually results in the candidate responding that they’ll just suck it up and work longer hours. Whether the candidate really will do that isn’t truly known, but it’s probably the safest response during an interview. Clearly, behavioral interviewing produces better results. Train your interview team to use behavioral questioning. You can use the attached one-page document to provide an overview of behavioral vs. situational interviewing.

The Cookbook

Source, Filter, Validate, Close

The hiring engine usually includes some version of the four phases above. I’ll assume that you have a recruiter sourcing candidates and doing the first round of filtering. The recruiter’s job should be to provide a short list of candidates that have a good chance of being a fit. Recruiters rarely have the technical experience to effectively validate the skills of all the roles they have to fill, but a seasoned recruiter should be very good at filtering. Filtering generally involves some combination of the following:

  • Ensuring the candidate’s goals align with the company’s opportunity
  • Evaluating the candidate’s communication skills
  • Determining at a high-level if the candidate’s past roles provide the foundation to perform the responsibilities of the position
  • Assessing logistical fit with the role (timeframe, travel expectations, work location, relocation, etc.)
  • Performing initial due diligence (work authorization status, work location, compensation and title expectations, readiness to make a change, etc.)
  • Providing background information about the company
  • Selling the role
  • When at the appropriate stage in the process, performing final due diligence (background checks, reference checks, verification of degrees/certifications, etc.)

Once a candidate clears the filtering process, the interview team validates the candidate’s fit. I generally ask the interview team to cover the following topics: cultural fit, manageability, and technical skill. One person (usually the recruiter) covers the cultural fit. The hiring manager should cover manageability and may cover some technical topics. A technical lead and one or more colleagues should cover technical skills.

To help guide your behavioral interviewing, I’ve put together the following list of cultural and manageability questions, along with some simple forms you can use guide your questions and capture the candidate’s responses:

Cultural Interview Questions

(downloadable form here, 148K)

  1. Why are you looking for another job?
  2. What are you looking for in a job? What are your goals?
  3. Describe a time where you worked on a project with an unreasonable deadline.
  4. Describe a time where you worked in an environment with very little structure.
  5. Describe a time where you were asked to work on something you were unfamiliar with.
  6. Describe a time where you had to take a risk.
  7. Describe a time where you had to move faster than you were prepared to move.
  8. Describe a time where you had to choose between working on an immediate task vs. meeting the needs of another person.
  9. Describe a time where you were faced with choosing between individual achievement and team achievement.
  10. Describe a time where you had to work within an established process that you disagreed with.
  11. Describe your three biggest strengths and your three biggest weaknesses.

Manageability Interview Questions

(downloadable form here, 149K)

  1. Describe a time where you had a conflict with a co-worker.
  2. Describe a time where you disagreed with the decision of a subordinate.
  3. Describe a time where you had a difference of opinion with a co-worker.
  4. Describe a time where you worked with an under-performing co-worker.
  5. Describe a time where you were asked to work on something you did not enjoy.
  6. Describe a time where you disagreed with the direction of a project or with a decision made by management.
  7. Describe a time where you didn’t feel heard.

Technical Interviews

Because of the broad range of technical topics possible, it’s beyond the scope of this article to provide a sample list of technical questions. However, one thing I strongly believe in during the interview process is asking candidates to produce some work related to what the role needs. If you are trying to hire a programmer, then ask them to write some code that solves a problem. A simple Google search on “Java programming problem and solution” will provide a number of useful web resources such as If the candidate needs strong written communication skills, a Google search on “writing tests” will point you to resources such as IELTS academic writing practice tests. Asking them to produce some real work products in your office often separates someone with true skill from someone who is just buzzword-compliant or who merely holds paper credentials without real capabilities. In some cases, online tools or tests (such as those found on and can supplement the interview process and reduce the time or effort needed to vet a candidate’s technical skills.


Before the candidate leaves, either the recruiter or the hiring manager should conduct a wrap up conversation. Topics to cover may include:

  1. How does the candidate feel the day went?
  2. What do they like about the company?
  3. What concerns do they have about the company?
  4. What do they like about the role?
  5. What concerns do they have about the role?
  6. How does this opportunity align with their goals and objectives?
  7. What other opportunities are the candidate currently considering?
  8. What considerations would lead the candidate to choose this opportunity over other opportunities in play?
  9. What questions does the candidate still have about the company or the opportunity?
  10. When would the candidate look to make a decision about their next role?


At the end of the interview, the interview team should reconvene and summarize their portion of the interview and provide their individual recommendation (hire, don’t hire, need more information to decide). Finally, the recruiter should collect the actual notes from each member of the interview team. Having the notes will help justify any decisions not to hire the candidate in the unlikely event that the candidate accuses the company of bias and/or threatens legal action.

If the interview team recommends hiring the candidate, the hiring manager and/or executive take responsibility to assemble a compelling job offer. The closing team should use the candidate’s responses to the wrap-up questions above to help close the deal.

Hopefully, this framework provides the foundation for you to set up a robust hiring engine so you can find the most qualified candidates to grow your company.