Organizational Debt is like Technical debt – but worse

Startups focus on speed since they are burning cash every day as they search for product/market fit. But over time code/hardware written/built to validate hypotheses and find early customers can become unwieldy, difficult to maintain and incapable of scaling. These shortcuts add up and become what is called technical debt. And the size of the problem increases with the success of the company.organizational debt

You fix technical debt by refactoring, going into the existing code and “cleaning it up” by restructuring it. This work adds no features visible to a user but makes the code stable and understandable.

While technical debt is an understood problem, it turns out startups also accrue another kind of debt – one that can kill the company even quicker – organizational debt. Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.

Just when things should be going great, organizational debt can turn a growing company into a chaotic nightmare.

Growing companies need to understand how to recognize and  “refactor” organizational debt.


I had lunch last week with Tom, the CEO of a startup that was quickly becoming a large company – last year’s revenue was $40M, this year likely to be $80M maybe even $100 million in ad revenue. They had reinvented a traditional print media category onto web and mobile devices for a new generation of users who were no longer buying magazines but reading online. Their content was topical, targeted and refreshed daily. Equally important their VP of Marketing had brilliantly executed a stream of social media campaigns (Facebook likes and partnerships, email campaigns, etc.) to drive traffic to their site, which they then turned into ad revenue.

Tom was excited about their next big round of funding that valued them at almost ½ a billion dollars. He talked about how they were trying to maintain their exponential growth and told me how many people they were adding, and the issues of scaling that rapidly. (They had doubled headcount from 100 to 200 in the last year and were planning to double again.) While he kept bringing the conversation back to their big valuation I tried to steer the conversation back to how they were going to deal with:

  • training the influx of new hires – in both culture and job specific tasks
  • retaining their existing hires who were working for intern-like salaries with little equity.

His answer centered on the great location of the new building, what great furniture they were getting, and the compensation plans for the key members of the executive staff.

This didn’t feel good.

They’ve Never Run A Company
Since the meeting had been a courtesy to Phillipe, one of their VC board members, I grabbed coffee and asked him what scaling challenges he saw for the company. I was taken aback when I got a reply that sounded like VC buzzword bingo – phrases like “They’re a platform not a product” and the ever popular “they’re a potential Unicorn.”

While the strategy sounded like a great long-term plan, I poked a bit and asked, “So what’s the training and onboarding plan for the new hires? What are you doing about the pay scales at the bottom of the organization? Aren’t you concerned about losing qualified people that the company spent the last few years training but never compensated adequately?” I got answers that sounded like the Tom’s – new stock grants for the executive staff, great new building, and oh, by the way, Tom and his co-founder got to sell some stock in the new round. And let me tell you about the vision and strategy again.

As Phillipe kept talking I listened but not really, because I started realizing that while he was a genius in finding and nurturing great early-stage deals, and had a vision that sounded great for the new investors, he didn’t have a clue about how to actually scale a company. He had never run one, and worse, had never been on a board of a startup making the transition from searching for a business model and product/market fit, to the next phase of “building” the infrastructure to support scale.

Unless they were planning to flip this company, organizational debt was going to hit faster than they could imagine. They needed a plan to “refactor” organizational debt. And Tom wasn’t going to get it from his board.

Focus on Bottoms Up as well as top Top Down
While the company had a great plan for keeping the top executives, and had all the startup perks like free food and dogs at work, they had spent little time thinking about the organization debt accruing with first 100 employees who had built the company underneath them. These were the employees that had the institutional knowledge and hard-earned skills. Originally they had been attracted by the lure of being part of a new media company that was disrupting the old, and were working for low salaries with minimal stock. And while that had been enough to keep their heads-down and focused on their jobs, the new funding round and onslaught of new employees at much higher salaries had them looking around and updating their resumes.

Surprisingly, given the tidal wave of new hires, formal training and job descriptions were still stuck in the early stage, “we’re too small to need that” mindset. The reality was that with hundreds of new employees coming on board the company desperately needed a formal onboarding process for new employees; first, to get them assimilated to the company culture and second, a formal process to train them in how to do their specific jobs. Unfortunately the people who could best train them were the underpaid employees who were now out looking for new jobs.

Organizational debt was coming due.

Organizational debt circled

“Refactoring” organizational debt
I had promised Tom the CEO we’d grab coffee again. When we did, I asked him about his head of HR, and heard all about what great medical and insurance benefits, stock vesting, automated expense account forms, movie night, company picnics, etc., the company had. I offered that those were great for an early-stage company, but it was time to move to a new phase (and perhaps a new head of HR.) Since Tom was an engineer I explained the “Organizational Debt” metaphor. He got it instantly and before I could even suggest it, he asked, “So how do I refactor organizational debt?”

I suggested that were seven things he could do – some quickly, some over time:

  1. Put together a simple plan for managing this next wave of hiring. Tell each hiring manager:
  • No new hires until you write/update your own job description.
  • Next write your new hire job description.
  • Next write how you will train new hire(s) in their functional job.
  • Next write how their job fits into each level upward and downward
  • And how it supports the mission of each level upward and downward
  1. Realize his expense plan is too low. I offered that it appeared he put together an expense budget using current employee salaries. If so, he was in danger of losing the people he most cared about keeping. He should stop thinking about 10% raises and start thinking about what he’d have to pay to replace employees who hold critical knowledge and train new ones. It felt to me more like 50% raises in quite a few cases.
    He needed to have his head of HR:
  • Do a salary survey of existing employees and industry comparables
  • Identify the employees they wanted to keep
  • Upgrade their salaries and equity ASAP

Some of the harder suggestions had to do with the organization as whole:

  1. He needed to consider refactoring some of the original hires and their roles. Some employees don’t scale from “Search” to this new phase of “Build”. Some because they are performance problems, or don’t fit a bigger organization, attitude etc. Some of these may be friends. Leaving them in the same role destroys a sense of what’s acceptable performance among new employees.  This is hard.
  2. In addition to refactoring the people, it’s time to relook at the company culture. Do the cultural values today take into account the new size and stage of the organization? What are the key elements that have “made it great” so far? Are they the same? different? how? why? It may be time to re-visit what the company stands for.
  3. Now that the company no longer fits in a conference room or even the cafeteria, it needs a way to disseminate information that grows with the organization. At times, this requires the same messages being repeated 4 or 5 times to make up for the fact the CEO isn’t always delivering them personally. Emphasize in the corporate messaging that while it is a period of rapid change, the company culture will be an anchor that we can rely upon for orientation and stability
  4. Does customer communication need to change? In the past any customer could talk to Tom or expected Tom to talk to them.  Is that feasible? Desirable?
  5. Finally, since this is new territory for Tom and board, create an advisory board of other CEOs who’ve been through the “build” stage from a startup to growing company.

Lessons Learned

  • Companies lucky enough to get to the “build” phase have a new set of challenges
    • They’re not just about strategy
    • It’s about fixing all the organizational debt that has collected
  • Onboarding, training, culture, and compensation for employees at the “build” phase all require a fresh look and new approaches
  • Failing to refactor organizational debt can kill a growing company

Episode 3 on SiriusXM Channel 111: Kathryn Gould, Mar Hershenson, Sophie Lebrecht

My guests this week on Bay Area Ventures on Wharton Business Radio on SiriusXM Channel 111 were:Untitled

  • Kathryn Gould co-founder of Foundation Capital
  • Mar Hershenson co-founder of the VC firm Pejman Mar Ventures
  • Sophie Lebrecht co-founder and CEO of Neon Labs

All three of my guests started their careers as scientists or engineers and ended up starting companies or venture capital firms.

Kathryn Gould is the co-founder of the VC firm, Foundation Capital and the owner of Battle Mountain Vineyard. kathryn gouldAs one of the first women VC’s in Silicon Valley she founded Foundation in 1995, and went on to be selected for the Midas List based on her investments. Since retiring from Foundation in 2006, Kathryn has helped MicroVC firms: Floodgate, Pejman Mar and Engineering Capital raise money and get started. In 2009 she and her husband started Battle Mountain Vineyard, where they make premium Cabernet wine.

Click on the links to listen to Kathryn Gould answer the questions:

—-

 

mar hershensonMar Hershenson is the Founding Partner at Pejman Mar Ventures. With her PhD in Electrical Engineering from Stanford, Mar taught the Analog Circuit Design course at Stanford for over a decade. She has co-founded three companies and been awarded both the T35 Young Innovator Award by MIT for her technical work and the Marie R. Pistilli Women in EDA Achievement Award for her work in design automation.

Click on the links to listen to Mar Hershenson answer the questions:

—-

sophie lebrechtSophie Lebrecht has her PhD in Cognitive Science from Brown University, and is currently the CEO and Co-Founder of Neon Labs where she has continued her innovative work extracting and ranking images that are best at attracting online clicks. Neons proprietary science has unlocked the answer to how the human brain responds to images and how that response translates to increases in audience engagement and monetization of visual content. Sophie was named as one of Fast Company’s 100 most creative people in business.

Click on the links to listen to Sophie Lebrecht answer the questions:

—-

Tune in on SiriusXM Channel 111 Monday June 29th 4pm PST/7pm EST for our next interesting program – Hacking for Defense in Silicon Valley.

Doubling Down On a Good Thing: The National Science Foundation’s I-Corps Lite

I’ve known Edmund Pendleton from the University of Maryland as the Director of the D.C. National Science Foundation (NSF) I-Corps Node (a collaboration among the University of Maryland, Virginia Tech, George Washington, and Johns Hopkins). edmund pendeltonBut it wasn’t until seeing him lead the first I-Corps class at the National Institutes of Health that I realized Edmund could teach my class better than I can.

After seeing the results of 500+ teams through the I-Corps, the NSF now offers all teams who’ve received government funding to start a company an introduction to building a Lean Startup.

Here’s Edmund’s description of the I-Corps Lite program.

SBIR/STTR Program and Startup Seed Funding
The Small Business Innovative Research (SBIR) and Small Business Technology Transfer (STTR) programs are startup seed funds created by Congress to encourage U.S. small businesses to turn Government-funded research into commercial businesses. Eleven U.S. agencies participate in the SBIR/STTR program, with DOD, HHS (NIH), NSF, DOE, and NASA offering the majority of funding opportunities.SBIR and STTR program

The SBIR/STTR program made ~6,200 seed stage investments in 2014, dwarfing the seed investments made by venture capital. seed stage investmentThe SBIR/STTR program represents a critical source of seed funding for U.S. startups that don’t fit whatever’s hot in venture capital. In fact, half of all seed stages in tech companies in the U.S. were funded by the SBIR program.

The SBIR/STTR program
The SBIR/STTR program funds companies in three phases. Phase I funding is for teams to prove feasibility, both technical and commercial.

Since most of the founders come from strong technical roots, companies in Phase I tend to focus on the technology – and spend very little time understanding what it takes to turn the company’s technology into a scalable and repeatable commercial business.

SBIR PhasesIn 2011 the National Science Foundation recognized that many of the innovators they were funding were failing – not from an inability to make their technologies work – but because they did not understand how to translate the technology into a successful business. To address this problem, the NSF collaborated with Steve Blank to adapt his Lean LaunchPad class at Stanford for NSF-funded founders. By focusing on hypothesis testing, the Lean LaunchPad had actually developed something akin to the scientific method for entrepreneurship. (see here, here and the results here.) This was an approach that would immediately make sense to the scientists and technologists NSF was funding. Steve and the NSF collaborated on adapting his curriculum and the result was the 9-week NSF I-Corps program.

NSF’s original I-Corps program was specifically designed for academic innovators still in the lab; fundamentally, to help them determine the best path to commercialization before they moved to the start-up stage. (I-Corps participants are at the “pre-company” stage.) But NSF realized the Lean LaunchPad approach would be equally beneficial for the many startups they fund through the SBIR/STTR program.Icorps plus SBIR

The “Beat the Odds” Bootcamp – an I-Corps “Lite”
The good news is that the NSF found that the I-Corps program works spectacularly well. But the class requires a substantial time commitment for the founding team to get out of the building and talk to 10-15 customers a week, and then present what they learned – the class is essentially a full time commitment.

Was there a way to expose every one of ~240 companies/year who receive a NSF grant to the I-Corps? The NSF decided to pilot a “Beat the Odds Boot Camp” (essentially an I-Corps Lite) at the biannual gathering of new SBIR/STTR Phase I grantees in Washington.

Steve provided an overview of the Lean LaunchPad methodology in an introductory webinar. Then the companies were sent off to do customer discovery before coming to an optional “bootcamp workshop” 12 weeks later. Four certified I-Corps instructors provided feedback to these companies at the workshop. The results of the pilot were excellent. The participating companies learned a significant amount about their business models, even in this very light-touch approach. The NSF SBIR/STTR program had found a way to improve the odds of building a successful company.Icorps lite plus sbir

During the past two years, I’ve taken the lead to expand and head up this program, building on what Steve started. We now require the participating companies to attend kick-off and mid-point webinars, and to conduct 30 customer interviews over the twelve-week program. The companies present to I-Corps instructors at a “Beat the Odds Bootcamp” – the day before the biannual NSF Phase I Grantee Workshop.

In March we conducted our fourth iteration of this workshop with a record number of companies participating (about 110 of 120, or 90%) and 14 certified I-Corps instructors giving feedback to teams. This time, we added afternoon one-on-one sessions with the teams in addition to group presentations in the morning. Companies are very happy with the program, and many have requested even more face time with I-Corps instructors throughout the process.

The smart companies in Phase I realize that this Bootcamp program provides a solid foundation for success in Phase II, when more dollars are available.

What’s Next
Currently, once these teams leave I-Corps Lite, they do not have any “formal” touch points with their instructors. Over time, we hope to offer more services to the teams and develop a version of I-Corps (I-Corps-Next?) for Phase II grantees.

We envision even greater startup successes if SBIR/STTR funded teams can take advantage of I-Corps classes through their entire life cycle:

  • “Pre-company” academic researchers – current I-Corps
  • Phase I SBIR/STTR teams – current I-Corps Lite
  • Phase II SBIR/STTR teams – develop a new I-Corps Next class

Icorps next plus SBIR ii and iii

The emphasis and format would change for each, but all would be solidly rooted in the Lean LaunchPad methodology. And of course, we don’t want to stop with only NSF teams/companies…as we all know. The opportunity is huge, and we can have a significant impact on the country’s innovation ecosystem.

Summary
NSF led the development of the SBIR program in the late 1970s. It has since been adopted by the entire federal research community. We believe NSF’s leadership with I-Corps will deliver something of equal significance… a program that teaches scientists and engineers what it takes to turn those research projects into products and services for the benefit of society.  I-Corps Lite is one more piece of that program.

Lessons Learned

  • The SBIR/STTR program is a critical source of seed funding for technology startups that don’t fit the “whatever’s hot” category for venture capital
  • The program is a national treasure and envied around the world, but we can (and should) improve it.
  • SBIR/STTR Phase I applicants needed more help with “commercial feasibility”…a perfect fit for business model design, customer discovery and agile engineering – so we rolled out the NSF I-Corps
  • The I-Corps was so successful we wanted more NSF funded entrepreneneurs, not just a select few, to be exposed to the Lean methodology – so we built I-Corps Lite

Why Build, Measure, Learn – isn’t just throwing things against the wall to see if they work

I am always surprised when critics complain that the Lean Startup’s Build, Measure, Learn approach is nothing more than “throwing incomplete products out of the building to see if they work.”

Unfortunately the Build, Measure, Learn diagram is the cause of that confusion. At first glance it seems like a fire-ready-aim process.

It’s time to update Build, Measure, Learn to what we now know is the best way to build Lean startups.

Here’s how.


Build, Measure, Learn sounds pretty simple. Build a product, get it into the real world, measure customers’ reactions and behaviors, learn from this, and use what you’ve learned to build something better. Repeat, learning whether to iterate, pivot or restart until you have something that customers love.build measure learn

Waterfall Development
While it sounds simple, the Build Measure Learn approach to product development is a radical improvement over the traditional Waterfall model used throughout the 20th century to build and ship products. Back then, an entrepreneur used a serial product development process that proceeded step-by-step with little if any customer feedback. Founders assumed they understood customer problems/needs, wrote engineering requirements documents, designed the product, implemented/built the hardware/software, verified that it worked by testing it, and then introduced the product to customers in a formal coming out called first customer ship.

Waterfall Development was all about execution of the requirements document. While early versions of the product were shared with customers in Alpha and Beta Testing, the goal of early customer access to the product was to uncover bugs not to provide feedback on features or usability. Only after shipping and attempting to sell the product would a startup hear any substantive feedback from customers. And too often, after months or even years of development, entrepreneurs learned the hard way that customers were not buying their product because they did not need or want most of its features.

It often took companies three tries to get products right. Version 1 was built without customer feedback, and before version 1 was complete work had already started on version 2 so it took till version 3 before the customer was really heard (e.g. Microsoft Windows 3.0)

Best practices in software development started to move to agile development in the early 2000’s. This methodology improved on waterfall by building software iteratively and involving the customer. But it lacked a framework for testing all commercialization hypotheses outside of the building. With Agile you could end up satisfying every feature a customer asked for and still go out of business.

Then came the Build-Measure-learn focus of the Lean Startup.

Build-Measure-Learn
The goal of Build-Measure-Learn is not to build a final product to ship or even to build a prototype of a product, but to maximize learning through incremental and iterative engineering. (Learning could be about product features, customer needs, the right pricing and distribution channel, etc.) The “build” step refers to building a minimal viable product (an MVP.) It’s critical to understand that an MVP is not the product with fewer features. Rather it is the simplest thing that you can show to customers to get the most learning at that point in time. build measure learnEarly on in a startup, an MVP could simply be a PowerPoint slide, wireframe, clay model, sample data set, etc. Each time you build an MVP you also define what you are trying to test/measure. Later, as more is learned, the MVP’s go from low-fidelity to higher fidelity, but the goal continues to be to maximize learning not to build a beta/fully featured prototype of the product.

A major improvement over Waterfall development, Build Measure Learn lets startups be fast, agile and efficient.

The three-circle diagram of Build Measure Learn is good approximation of the process. Unfortunately, using the word “build” first often confuses people. The diagram does seem to imply build stuff and throw it out of the building. A more detailed version of the Build Measure Learn diagram helps to clarify the meaning by adding three more elements: Ideas-Build-Code-Measure-Data-Learn.

ideas build code measureThe five-part version of the Build Measure Learn diagram helps us see that the real intent of building is to test “ideas” – not just to build blindly without an objective. The circle labeled “code” could easily be labeled “build hardware” or “build artificial genome.” The circle labeled “data” indicates that after we measure our experiments we’ll use the data to further refine our learning. And the new learning will influence our next ideas. So we can see that the goal of Build-Measure-Learn isn’t just to build things, the goal is to build things to validate or invalidate the initial idea.

The focus on testing specific ideas counters the concern that build-measure-learn is just throwing things against the wall and see if they work.

But it’s still not good enough. We can now do better.

Start With Hypotheses
What Build-Measure-Learn misses is that new ventures (both startups and new ideas in existing companies) don’t start with “ideas”, they start with hypotheses (a fancy word for guesses.) It’s important to understand that the words “idea ” and “hypotheses” mean two very different things. For most innovators the word “idea” conjures up an insight that immediately requires a plan to bring it to fruition. In contrast, a hypothesis means we have an educated guess that requires experimentation and data to validate or invalidate.

These hypotheses span the gamut from who’s the customer(s), to what’s the value proposition (product/service features), pricing, distribution channel, and demand creation (customer acquisition, activation, retention, etc.)

That the Lean Startup begins with acknowledging that your idea is simply a series of untested hypotheses is a big idea. It’s a really big idea because what you build needs to match the hypothesis you want to test.

The minimum viable product you’ll need to build to find the right customers is different from the minimum viable product you need for testing pricing, which is different from an MVP you would build to test specific product features. And all of these hypotheses (and minimal viable products) change over time as you learn more. So instead of Build-Measure-Learn, the diagram for building minimal viable products in a Lean Startup looks like Hypotheses – Experiments – Tests – Insights.hypotheses experiment

Generating Hypotheses
Using this new Hypotheses – Experiments – Tests – Insights diagram the question then becomes, “What hypotheses should I test?” Luckily Alexander Osterwalder’s business model canvas presents a visual overview of the nine components of a business on one page. They are:

  • value proposition, product/service the company offers (along with its benefits to customers)
  • customer segments, such as users and payers or moms or teens
  • distribution channels to reach customers and offer them the value proposition
  • customer relationships to create demand
  • revenue streams generated by the value proposition(s)
  • activities necessary to implement the business model
  • resources needed to make the activities possible
  • partners 3rd parties needed to make the activities possible
  • cost structure resulting from the business model

Business Model Canvas

And it brings us to the definition of a startup: A startup is a temporary organization designed to search for a repeatable and scalable business model.

Testing Hypotheses
And once these hypotheses fill the Business Model Canvas, how does an entrepreneur go about testing them? If you’re a scientist the answer is easy: you run experiments. The same is true in a Lean Startup. (The National Science Foundation described the Lean LaunchPad class as the scientific method for entrepreneurship.)

The Customer Development process is a simple methodology for taking new venture hypotheses and getting out of the building to test them. Customer discovery captures the founders’ vision and turns it into a series of business model hypotheses. Then it develops a series of experiments to test customer reactions to those hypotheses and turn them into facts. The experiments can be a series of questions you ask customers but most often a minimal viable product to help potential customers understand your solution accompanies the questions.

So another big idea here is startups are not building minimal viable products to build a prototype. They are building minimal viable products to learn the most they can.

HBR Reprint

Finally, the goal of designing these experiments and minimal viable products is not to get data. The data is not the endpoint. Anyone can collect data. Focus groups collect data. This is not a focus group. The goal is to get insight. The entire point of getting out of the building is to inform the founder’s vision. The insight may come from analyzing customer responses, but it also may come from ignoring the data or realizing that what you are describing is a new, disruptive market that doesn’t exist, and that you need to change your experiments from measuring specifics to inventing the future.

Lessons Learned

  • Build, Measure, Learn is a great improvement over Waterfall product development and provided the framework to truly join the customer to agile development
  • However, emphasizing “Build” or “Ideas” as the first step misses the key insight about a Lean Startup – you are starting with hypotheses to be tested and are searching for repeatable and scalable business model
  • Hypotheses, Experiments, Test, Insights better represents the Lean startup process:
    • Use the Business Model Canvas to frame hypotheses, Customer Development to get out of the building to test hypotheses, and Agile Engineering to build the product iteratively and incrementally

How One Startup Figured Out What Could Really Help Deaf People

Thibault Duchemin and his team applied for our Lean LaunchPad class at UC Berkeley in 2014. We accepted them because it was clear Thibault was driven to solve a very personal problem – he grew up in a Deaf family, the only one who could hear. His team project was to provide automated aids for the hearing impaired.

Here’s his story.

——-

Lean LaunchPad: A Year After
A month ago, Jason, one of my founder friends, shut down his startup. It failed because he forgot the No. 1 rule every founder hears over and over: Nobody wants your product until you prove it.

How come so many founders still wake up to this horrible truth, after months or years of hard work?

Listening to Jason’s story made me realize how critical our experience with the Lean LaunchPad has been in our entrepreneurial journey at Transcense. And why now, despite the time and effort involved, we do not hesitate getting out of our office to meet users.

Pre-Lean LaunchPad – Giving a Voice to the Deaf
Everything started when I applied to the Lean LaunchPad class pitching a big, crazy idea to solve a personal problem of mine. I grew up the only hearing person in a Deaf family. My sister’s dream has always been to become a lawyer, but closing statements and client meetings are impossible situations for her without the help of unaffordable interpreters.

Thibault_sister

At Berkeley I decided to build smart gloves to translate sign language. With my co-founder Pieter, I built a first basic prototype, which got us a prize and got the team started. It looked like one of the geeky science projects you find in Berkeley halls. Glove nerds we became.started with a glove

That’s also when we met Steve Blank.

More than the signing glove, he was interested by our passion for the problem.

Steve knew that first ideas rarely hit home for users, so to enter the Lean LaunchPad, we had to give in. “We’re not married to the glove,” we said, allowing us to accept the possibility of a pivot. There was no going back.

Lean LaunchPad – Stumbling Upon an Immense Need
Customer Development for us meant a lot of hard-won learnings. Our entire team took a fast-paced American Sign Language course to be able to really connect with our potential users. We spent six weekly hours in complete silence, discovering the subtleties of gestures and expressions. Since I’m French, I spoke for a while a bizarre Franglish in signs. It turned out to be out an excellent icebreaker in our interviews.

After 61 in-person discussions, and hundreds of bike rides across the Bay Area to meet and talk/sign/write for hours with our potential users, we were sure that the community of Deaf people cheered for our signing glove idea and prototype.

But we detected a common frustration when discussing their existing relationships with their hearing coworkers or friends, where the glove couldn’t help at all. This one thing kept coming back across all our interviews, over and over. A frustration so obvious, yet so deeply unresolved that when it became really apparent the day we met Alma, it blew our minds away and made us pivot.

Alma didn’t speak sign language, and relied on her residual hearing, being able to read lips very well in face-to-face situations. But in her own family, at the dinner table, she would read a book while everybody else was conversing.make do

Why?

Because following the conversation when multiple people were talking around her was impossible. She avoided the problem the best way she could, by doing something else, or being somewhere else.

We learned that existing solutions are not affordable enough to access in easy, informal social and professional conversational situations. For 400M people in the world with disabling hearing loss, this is an ongoing frustration, encountered every day. This was a big opportunity.

Halfway through the Lean LaunchPad, it was time for a major pivot. We dropped the signing glove.

And pivoted to a mobile application that transcribes group conversations using speech-recognition technologies. The app quickly connects all the smartphones in a group, enabling the app to translate and display who said what around the user (while uniquely identifying each speaker) in less than a second. With 24/7 autonomy, it allowed our deaf/hard-of-hearing user to understand and participate in any group situation, effortlessly.

The rest of the 123 total interviews helped us figure out a working business model. By the time we graduated from the Lean LaunchPad class, we had found the root cause of the initial problem we had set out to tackle, and even better, a potential solution for it.a device to understand themPost-Lean LaunchPad – Making Something People Need
Now it was time to build the company. Our team spent our whole summer in Berkeley iterating, testing and running experiments to validate and refine our concept before spending any of our precious resources. For example, we built a “mock-up meeting”, where 5 friends in the meeting called 5 more friends of ours who each transcribed the call to be interfaced to a Deaf tester in the room. Despite the low fidelity of this minimal viable product, some of our testers thought it was a real technology.

a device to understand them2Next, we joined the Boost.vc startup accelerator, where we spent 16 hours a day in a basement to finish the first working version of our app. By now we believed we had tested our hypotheses and wanted to validate whether there was a market. So we launched a crowdfunding campaign on Indiegogo. We raised $30,000 in less than 6 days, almost doubling our goal. The endless emails we received describing the exact need we had uncovered were the powerful validation of the customer development approach.

Now – Bridging the Communication Barrier
Skinner, our third cofounder, joined because of our persistence in talking to our users. The captioner (live-transcriber) we used in demoing to potential deaf customers was so excited about our product that she introduced us to Skinner, a brilliant mobile developer, who is profoundly deaf.

In the early days of Transcense, when we took Skinner to an event, he would grab a drink and go to an isolated space to check his phone. Today, in small groups, he can use the app to communicate with others. At lunch, during our internal meetings, we pull out our phones and stay connected, transcending the silence barrier. What was just my personal story now became a team story while we slowly dissolved the communication barriers within the team.

trancense

Every day, these simple moments justify our long hours of work.

But what’s ahead of us is even more exciting.

After a 3-months of beta testing with our community, we’ve seen the same pattern with our early users – we’ve changed their lives, enabling opportunities that had been closed to them so far. Incredibly high usage and impressive retention prove that we are on the right track.

So what now?

In a relentless build-measure-learn cycle, we’re staying focused on the next steps.

We are bridging the deaf/hearing communication gap, an immense mission that will take everyone’s participation to make it happen.

Lessons Learned

  • Dig deep into your customer psychology and test lo-fidelity minimum viable products, before trying to build anything
  • Track the need rather than the desire: solving somebody’s needs will help you much more
  • Eat your own dog food

Hacking For Defense In Silicon Valley

Lead, follow or get the heck out of the way

In peacetime the U.S. military is an immovable and inflexible bureaucracy. In wartime it can adapt and adopt organizational change with startling speed.

BMNT, a new Silicon Valley company, is combining the Lean Methods it learned in combat with the technology expertise and speed of startups.

—–

But first some history…

World War II
In World War II the U.S. government reengineered its approach to building weapons. In a major break from the past, where the military designed all its own weapons, 10,000 scientists and engineers from academia worked in civilian-run weapons labs (most headquartered in universities) in an organization called the Office of Scientific Research and Development (OSRD).

OSRD was tasked to develop military weapons systems and solve military problems but had wide autonomy to determine how to accomplish its tasks and organize its labs. (The weapons were then manufactured in volume by U.S. corporations.)

OSRD

The OSRD developed advanced electronics: radar, electronic warfare, rockets, sonar, proximity fuse, Napalm, the Bazooka and new drugs such as penicillin and cures for malaria. One OSRD project – the Manhattan Project  – the development of the atomic bomb – was so secret and important that it was spun off as a separate program. The University of California managed research and development of the bomb design at Los Alamos while the US Army managed the Los Alamos facilities and the overall administration of the project.

After the war the U.S. split up the functions of the OSRD. Nuclear weapons went to the new Atomic Energy Commission (AEC), basic weapons systems research went to the Department of Defense (DOD) and all U.S. biomedical and health research went back to the National Institutes of Health (NIH). In 1950, government support of basic science research in U.S. universities became the charter of the National Science Foundation (NSF). Each of these independent research organizations would support a mix of basic and applied research.

The Cold War
During the Cold War the U.S. and the Soviet Union faced off with a nuclear deterrence policy called mutually assured destruction (aptly named MAD.) But to fight a conventional war in Europe, Soviet forces had built a 3 to 1 advantage in tanks, artillery, armored personnel carriers, and soldiers. In response the U.S. developed a new strategy in the late 1970’s to counter the Warsaw Pact. Instead of matching the U.S.S.R. tank for tank or solider to solider, the U.S. saw that it could change the game and take advantage of a lead we had that was getting longer every day – using our computer and chip technology to aggressively build a new generation of weapons that the Soviet Union could not. 

At the heart of this “offset strategy” was “precision strike,” – building stealth aircraft to deliver precision guided munitions unseen by enemy radar, and designing intelligence and reconnaissance systems that would target for them. The offset strategy was smart weapons, smart sensors, and stealth using silicon chips, electronics and computers that only the U.S. could design and produce.

By the mid-1980’s the Soviet military was struggling to keep up with this “revolution in military affairs. The announcement of the Strategic Defense Initiative (Star Wars) further destabilized the Soviet Union.

The Gulf Wars
When I first started teaching customer development (searching, validating and executing a business model), one of my students pointed out that customer development was similar to the theory of a military strategist, John Boyd. In the 1960’s, Boyd, who was a fighter pilot, proposed that instead of executing a fixed plan, wars would be won by those who can Observe, Orient, Decide and Act (the OODA Loop.) After being ignored for decades, Boyd’s OODA Loop drove the U.S. war fighting strategy in both Gulf Wars. The OODA Loop was the Lean Startup philosophy before lean.

Large ooda loop

Iraq, Afghanistan and the Army’s Rapid Equipping Force (REF)
In Afghanistan in 2002 U.S. soldiers were tasked to clear caves that the Taliban used to store equipment. Many of the caves still had Taliban fighters inside while others had been booby-trapped. To clear the caves soldiers threw grappling hooks inside then pulled the hooks out to catch trip-wires and explode bombs. But often this technique did not work and soldiers died. The Army realized they needed to do something more effective. They gave the problem to Colonel Bruce Jette, and 90 days and $750,000 later he had bypassed the existing Army acquisition system and bought existing robots from companies. Exponent provided the PackBot and the Marcbot and deployed them to the field.

From that day the Army’s Rapid Equipping Force (REF) was born.

The REF’s goal is to deliver technology solutions to front-line soldiers in days and weeks, instead of months and years either by using solutions from previous REF efforts or existing government- or commercial-off-the-shelf technologies purchased with a government credit card.

The REF had permission to shortcut the detailed 100+ page requirements documents used by the defense acquisition process. It developed a ten-line short form that listed the most important parts of the requirement. The REF also had its own budget, which it could use to acquire equipment.

Soon the REF was sending teams of civilian and military subject matter experts out into the field to discover what they needed. REF expanded its operations to include forward teams in Kuwait and Iraq to provide technology to fill capability gaps and to counter the highest priority threats.

By the end of 2007, the REF had delivered more than 550 types of equipment and more than 75,000 individual items. The average time from receiving a request from the field to delivering a solution to the soldiers was 111 days.

In 2010 Colonel Peter Newell took over the REF and turned its focus into what we would call a Lean Startup. Pete Newell
Newell insisted that REF started with a deep understanding of soldiers’ problems
 before purchasing a proposed solution. Newell found that four problems accounted for two-thirds of REF requirements:

  1. defeating roadside bombs
  2. supporting soldiers on foot with communications and load carrying devices
  3. providing soldiers with timely intelligence, surveillance, and reconnaissance in combat
  4. supplying and protecting small isolated combat outposts

He came up with his version of the OODA loop to explain to people how REF should behave.

REF Problem Solving Cycle

To get closer to his customers, Newell commissioned three mobile laboratories that were airlifted to forward operating bases. These labs included a Computer Numerical Control milling machine and 3-D printers for rapid prototyping.REF Mobile Lab

Hacking For Defense (H4D)
When Colonel Peter Newell left the Army, he came to Silicon Valley at the urging of a friend and fellow retired Army Colonel, Joe Felter, a Stanford PhD who moved to Palo Alto and Stanford after a career in the Special Forces. Newell accepted Felter’s invitation to join a company he had originally established. BMNT does for the Department of Energy, the Department of Defense and the Intelligence Community what the REF did for the U.S. Army – build teams that deliver solutions to complex problems, with access to the entire network of suppliers and partners that Newell and Felter developed throughout their careers.

To tap into the innovation of Silicon Valley, BMNT, in collaboration with Stanford’s Preventive Defense Project organized Hacking For Defense (H4D) – a series of hackathons – to help the Department of Defense do four things:

  1. Identify new ideas that will solve problems the military expects to see in the future
  2. Map those ideas to the technology that could be used to solve them
  3. Recruit the people who can make it happen
  4. Show the DoD how to engage Silicon Valley with challenging problems and build networks of people to solve them

BMNT‘s first hackathon, “Hacking the Supply Chain,” brought together diverse teams of technologists and users to provide solutions to the questions: How do you supply troops which can be sent on short-notice, for long periods to places where there are no existing bases or supplies? How might we create the most resilient and efficient supply chain possible for our forward-deployed land forces in 2025?

“Hacking the Supply Chain” is focused on:

  • energy and power generation
  • potable water and field expedient sewage systems
  • advanced manufacturing and repair maintenance technologies
  • training and readiness technologies
  • command, control, computers, and communications technologies

In mid-April, the ideas generated at BMNT‘s first hackathon will be presented to a panel of experienced senior entrepreneurs, engineers, and military and government officials and then sent to the Department of Defense with specific recommendations on the technologies with potential to support them.

Ultimately Newell and Felter say they want to use BMNT to create an “insurgency” in Silicon Valley to get cutting-edge innovation into the organizations defending our country. (Click here for information on Hacking for Defense events.)

Hacking the Prime’s
In reality, what BMNT is trying to fix is the way the Department of Defense acquires radically new technology and ideas. While DARPA tries to fill that need, today the primary conduits for bringing new technology to the government are the prime contractors (e.g., Lockheed, Boeing, Raytheon, Northrup Grumman, L3, General Dynamics, et al.) But most of these contractors focus on fulfilling existing technology needs that can be profitable.

If a startup wants to provide new technology to the Department of Defense (DoD),  they have to sell through the prime contractors who own the relationships with the DoD. Most startups and innovative companies are unwilling to risk exposing their Intellectual Property and go through the paperwork of dealing with the government, so they choose not to pursue government ventures. In this way, the primes artificially restrict DoD’s technological funnel.  (Palantir is the most visible Silicon Valley insurgent in this space.)

Today, incentives for bringing innovation into the government with speed and urgency are not aligned with the government acquisition, budgeting, and requirements process. As a result, the DoD fails to acquire truly innovative technologies (much less paradigm-changing technologies) in a timely fashion.

Lessons Learned

  • In peacetime the U.S. military is an immovable and inflexible bureaucracy
  • In wartime it can adapt and adopt organizational change with startling speed
  • The Rapid Equipping Force operated with speed and urgency to deliver solutions to real customer problems
  • BMNT and Hacking for Defense are trying to bring this same process to Silicon Valley

Getting to “Yes” for Corporate Innovation

I’ve been working with Roberto, the Chief Innovation Officer of a diversified company I’ll call Sprocket Industries.

I hadn’t heard from Roberto in awhile and when we caught up, it was clear his initial optimism had faded. I listened as Roberto listed the obstacles to the new innovation program at Sprocket, “We’ve created innovation teams in both the business units and in corporate. Our CEO is behind the program. The division general managers have given us their support. But the teams still run into what feel like immovable obstacles in every part of the company. Finance, HR, Branding, Legal, you name it, everyone in a division or corporate staff has an excuse for why we can’t do something, and everyone has the power to say no and no urgency to make a change.”

Roberto was frustrated, “How do we get all these organizations to help us move forward with innovation? My CEO wants to fix this and is ready to bring in a big consulting firm to redo all our business processes.”

Uh oh…

—–

As Sprocket’s Chief Innovation Officer, Roberto was a C-level executive responsible for the corporate innovation strategy in a multi-billon dollar company. Over the last 9 months his staff got innovation teams operating with speed and urgency. The innovation pipeline had been rationalized. His groups whole-heartedly adopted and adapted Lean. His organization ran a corporate incubator for disruptive (horizon 3) experiments and provided innovation support for the divisions for process and business model innovations (Horizon 1 and 2.) He had an innovation pipeline of hundreds of employees going through weekend hackathons and 45 different innovation teams going through 3-month rapid Lean LaunchPad programs to validate product/market fit.

The next day Roberto and I sat together and listed what we knew about the innovation conundrum at Sprocket:

  1. Sprocket is a permanent organization designed to execute a repeatable and scalable business model.
  2. Roberto’s innovation teams are temporary organizations designed to search for a repeatable and scalable business model.
  3. Sprocket had world-class resources and capabilities in brand, supply chain, distribution, sales force, financial metrics, all tailored to execute the existing business model, not to help search for a new one
  4. The resources and capabilities optimized for execution interfere with the processes needed to search for a new business model
  5. Sprocket needed new and different processes for innovation while retaining the ones that work well for execution
  6. Sprocket wanted to use the same organizations that provided support for execution (brand, supply chain, distribution, sales force, financial metrics) to provide support for innovation

Roberto’s group had spent the last 9 months educating the company about why they needed to deliver continuous innovation, and why the execution and innovation teams need to work collaboratively. But while there was lots of theory, posters, memos, and lip-service to being innovative, it wasn’t working.

So what to do?

I offered that a top-down revamp of every business process should be a last resort. I suggested that Roberto consider trying a 6-month experimental “Get to Yes” program. His teams, not outside consultants, would write their own innovation processes and procedures.Get to Yes

Recognizing the Roadblocks
Most of the impediments the innovation teams faced were pretty tactical: for example an HR policy that said the innovative groups could only recruit employees by seniority. Or a branding group that refused to allow any form of the Sprocket name to appear on a minimal viable product or web site. Or legal, who said minimal viable products opened the company to lawsuits. Or sales, who shut out innovation groups from doing customer discovery with any existing, or even potential customer. Or finance, who insisted on measuring the success of new ventures on their first year’s revenue and gross margin.

We agreed that the goal was not to change any of the existing execution processes, procedures, incentives, metrics but rather to write new ones for innovation projects.

And these innovation policies would grow one at a time as needed from the bottom of the organization, not top down by some executive mandate.

If we were successful, innovation and execution policies, processes, procedures, incentives, metrics would then co-exist side-by-side. In their day-to-day activities, the support organizations would simply ask, “Are we supporting an execution process (hopefully 90% of the time) or are we supporting an innovation process?” and apply the appropriate policy.

Get to Yes
The “Get to Yes” program was pretty simple. Every time an innovation team needed a new policy, procedure, etc. from an existing organization (legal, finance, sales, HR, branding, etc.), they submitted a standard Sprocket corporate “Get to Yes” request form. The form was a single page. It asked what policy the innovation group wanted changed, why it wanted it changed, how it wanted the new policy to read, the impact the new policy would have on other policies and organizations, and most importantly the risks to the core existing business.

The “Get to Yes” request form looked like this:

Sprocket Get to Yes Form page 1

The appropriate department had one week to ask questions, gather information, meet with the innovation team and evaluate the costs and risks of the proposed process. They could either:

  1. approve and adopt
  2. suggest modifications that the team agreed with
  3. deny the request.

The approval form looked like this:

Sprocket Get to Yes Form page 2

Although it was just a one-page form, the entire concept was radical:

  • The innovation team would be proposing the new process, procedure, metric, etc. – not waiting for one to be written.
  • There was a hard 1-week deadline for the execution team to respond.
  • Yes was the default answer, a No required detailed explanation.
  • Appeals went straight to the Chief Innovation Officer.

The big idea is that Sprocket was going to create innovation by design not by exception, and they were going to do it by co-opting the existing execution machinery.

The key to making this work was that if the request was denied, it automatically was kicked upstairs to the Chief Innovation Officer – and would be acted on the next week. And it’s there that the execution department had to make its case of why this request should not be approved. (If there was still no agreement, it became an issue for the executive staff.)

The time for a process resolution in a billion dollar corporation – two weeks. At Sprocket innovation was starting to move at the speed of a startup.

Lessons Learned

  • Innovation by design, not by exception
  • Execution organizations now manage both execution and innovation
  • Innovation teams write their own process and procedures
  • Innovation policy, process and procedures get written as needed, one at a time
  • Over time a set of innovation processes are created from the bottom up
  • Bias for immediate action not perpetual delay
Follow

Get every new post delivered to your Inbox.

Join 180,502 other followers