How I Became One of the .004%

A few weeks ago, I was asked to blog about the patent using Lean Start-up, before @EricReis wrote his first book.  Thanks to @adamberk for the suggestion, and here we go-

Based on numbers publish by U.S. Patent office and Inc. Magazine, roughly 150,000 patents are issued within the United States each year.  Not shockingly given the current state of women in STEM fields, only 8% of those U.S. Patents are awarded to women.  This means only 12,000 U.S. women per year become patent holders, on a U.S. population of approximately 340 Million. Any woman issued a U.S. is part of an exclusive .004% club.   I became a member of this exclusive .004% club in both 2010 and 2016.

This patent was not the result of expertise, but the disciplined use of Design Thinking and Lean Start-up methods.

In 2010, and twice in 2016, I was awarded patents for the design of a glucose meter.  Unique as a commercial product, this glucose meter recommends custom insulin doses for individual diabetics, under the care a physician.  So, I must be an MD?  A medical researcher?  Surely at the very least, I must know a diabetic?  The answer to these usual assumptions is “No”.  I had exactly zero experience with diabetes, medical devices, and had never even worked in the general area of consumer products.  In fact, this wasn’t even the specialty of Menlo Innovations, the company I contracted with at the time. 

If it wasn’t expertise that put me in the .004%, then what was it?  This patent was the result was the disciplined use of Design Thinking and Lean Start-up methods.   These methods require high levels of empathy, creativity, low ego, and collaborative capabilities.  Companies are consistently winning with Design Thinking, Lean Start-up, so their use is gaining traction in the market.  These approaches were creating opportunities women even before the terms were coined.  Here is how it worked for me.

A client company had a vision of a world where diabetics could, under the care of a physician, get customized recommendations for insulin from a programmable glucose meter.  They contracted with Menlo Innovations to design and build a product that would fulfill that vision.  Along with a partner, I was given the task to figure out what we needed to do to gather the data we needed, then to use that data to design the glucose meter. With no prior knowledge, we didn’t have many assumptions about the lives of diabetics, or even what made for a good glucose meter.  We decided to go to the source and start learning from diabetics.   

Starting with empathy for our potential customers and the fact that all use glucose meters. We devised an experiment that would incorporate both. 

Starting with empathy for our potential customers and the fact that all use glucose meters.  We devised an experiment that would incorporate both.  While we went to local drug stored and purchased every available glucose meter, Project Managers worked to identify diabetics who would be willing to meet us at Panera Bread for an hour to talk to us about their experience as a diabetic.  Within 2 days, we had 10 diabetics and 10 glucose meters and were ready to run an experiment to determine what diabetics thought was the best existing glucose meter on the market.

First, we met our subjects at Panera Bread for a 90 minute session.  For a $25.00 Panera gift card, our diabetic subjects spent the first half our simply talking about their life experience.  One of us took notes, while the other asked questions and then, when appropriate, deeper questions about the challenges life as a diabetic.  This helped us build a well-rounded understanding of the challenges facing diabetic patients in general, but also allowed us a deep pool of data to pull from when fleshing out a full picture for others who would eventually help build out the product.

…we asked them to think out loud about the choices they were making.

Second, we dumped all 10 glucose meters out on the table in front of our users and asked them to place them from left to right.  To the left of the line were the “I hate this” glucose meters, and to right, the “I love this” meters.  While these potential customers worked on their subjective placement from 1 to 10, we asked them to think out loud about the choices they were making.  We were very surprised by the amount of thinking they did during the process and the passion they felt about their choices.  All ten participants shared detailed feelings and personal stories about features, shapes, feel, and even colors of the meters, sometimes in far more detail than we would have ever anticipated.

Both the rational and irrational seemed to inform each person’s decision about whether they would place a meter in the 4th instead of the 5th position, or in the 9th instead of the 10th.  This process looked very messy and seemed very personal, subjective, and multivariate.  However, over ten such interviews and experiments, a very clear picture began to emerge about where there was agreement and triangulation, versus when there was an outlier.

The fact that many established product companies spend millions implementing new products and features without a single experiment with customers is shocking.

Third, we combined the data into findings, collaborated in a group to determine what was similar and what was unique feedback.  Interesting, there was no emerging leader in glucose meters, there were only leading Features and leading placements of Features.   It was from this initial experiment, with less than 3 weeks of calendar time, that the prototype design for the 2010 patent was created.  We then pulled from Agile, continuing to learn and create iterations of the initial prototype,  then run more experiments.  All-in-all, by running experiments in iterations, I spent less than 6 months on a project that yielded 3 patents.

It’s amazing that such simple and seemingly non-scientific experimentation with potential customers can be powerful, efficient, and even patent-worthy.

It’s a little counter intuitive that such simple and seemingly non-scientific experimentation with potential customers can be that powerful, efficient, and even patent-worthy.  The fact that many established product companies spend millions implementing new products and features without running even one experiment with customers is shocking.  It’s worth mentioning that this patent was commercialized both domestically and internationally.  This effort resulted in a commercial product as well.  I thank Menlo Innovations for enabling such rewarding work – Rich Sheridan remains ahead of the market in leveraging Design Thinking and Lean Start-up.

I would love to hear from others in the .004% - I invite you to respond or comment with your story and perhaps we can find a way to increase these numbers.  Do you know a .004% member?  please forward this to them…I understand many have been so busy they haven’t had time to do the math!

It's Time for Product Craftsmanship

The biggest challenge for Agile is no longer establishing SCRUM teams or creating working software - the challenge in today’s fast-moving economy is releasing software that will move customers to buy and move the needle for business.    In Agile, we practice Software Craftsmanship, but now the new imperative must be Product Craftsmanship.  Here’s why:

To quote the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” If we deliver early and continuously, do we know that we are also delivering value?   I ask myself these questions: Why doesn’t SCRUM, Kanban, or Scaled Frameworks result in market success? Why are enterprises with high-performing Agile teams still falling behind the competition?

Should we be satisfied with “better ways to create software” as an end goal, or is now the time to aim for something more meaningful?

As the community of “guiding Agilists,” we are becoming the root cause of brand erosion and market disruption for our clients.  We continue to “help” our clients iteratively release software that no one will buy, no one will use, and may ultimately cost our clients their share of the Digital Economy.  Should we be satisfied with “better ways to create software” as an end goal, or is it now time to aim for something more meaningful?  We could be delivering a competitive edge, enabling enterprise success, and yes, even creating higher stock prices for our clients.

Those of us who have spent years working on Transformation know that success depends on more than the software development organization, yet I have heard many seasoned colleagues dismiss success with users or the market as a “Business problem.” We may have a product owner, but we are light on helping their leadership truly understand Agile or how to create a backlog.  This attitude leaves product owners and product management teams alone to struggle with prioritizing and what valuable and usable means.

With only rare exceptions, technology teams still claim success and move on to the next big thing.

These business partners and stakeholders are also the folks left to live with the product (and customer feedback) released by the “high-performance team."  With only rare exceptions, technology teams still claim success and move on to the next big thing. This trend makes Agile Transformation and even Agile adoption spotty, with stalls and resets rampant. We focus on Software Craftsmanship, when this problem can only be solved with Product Craftsmanship.

From the beginning, the Agile Manifesto valued minimizing waste through minimizing documentation while encouraging collaboration and communications.  Lean adds more language around minimizing waste. However Agile and Lean do not merely suggest minimizing waste in all of its forms, they also encourage understanding of customers and economics. For example: What is the cost of delay for implementing one Feature before another?

Some of the tools of Product Craftsmanship are already seeing success in Agile. Those who have spent any time with the Scaled Agile Framework or read Don Reinertsen’s book The Principles of Product Development Flow can see elements of planning and prioritization based on value.  Reinertsen suggests “taking the economic view,” and Leffingwell prioritizes based on “weighted shortest job first.” But sadly, Agilists in these scenarios usually end up coaching a planning processes and assume that software craftsmanship and product craftsmanship already exist in the organization.

We must start coaching and teaching both Software Craftsmanship and Product Craftsmanship,  otherwise we will lead clients to disruption. 

So, who are the Product Craftsmen? In the Lean Start-up community, Eric Reis and colleagues such as Steve Blank, Brant Cooper, Alex Osterwalder, and Yves Pigner seem to have Product Craftsmanship well in hand. According to that community, you need to test your assumptions (or Hypotheses) in real time while developing an idea. You then pivot as needed, change your business model as you learn, and constantly “get out of the building” to gather data and validate what will truly be successful in the market.

A perfect example of this is a scene in the movie The Social Network in which Mark Zuckerberg is racking his brain, knowing the product didn’t yet have what it would take to be a success. A classmate named Dustin runs over:

DUSTIN: “There’s a girl in your art history class. Her name is Stephanie Attis. Do you happen to know if she has a boyfriend?”

MARK: “Why am I being interrupted?”

DUSTIN: “Have you ever seen her with anyone? And if not, do you happen to know if she’s looking to go out with anyone?”

MARK: “Dustin. People don’t walk around with a sign on them that says—“

Mark stops and realizes what his product needs to be successful: a relationship status. The rest is history.  Mark was successful because he left his dorm room, went out into the world, listened to his users, and immediately changed the product based on what he learned.  Turns out Facebook was somewhat successful.

It’s very likely that if your business isn’t doing what Mr. Zuckerberg did as a way of working, you might as well burn your investment money - you won’t build the right product. The Lean Start-up approach works, and some smart enterprises are already adopting as many aspects of this system as possible. Lean Startup is a proven way to assure a valuable Product Model and it puts you on the path to Product Craftsmanship.

In the meantime, what is the Agile Community offering? We say the product owner owns the backlog and for the most part, that’s the full extent of our participation in Product Craftsmanship. Sometimes we might say something that sounds impressive, but is merely time-based: “You need to break epics into features and then break those down into stories that will fit into an iteration”.  Where is the value? Where is the guidance to assure that value is being created based on solid, client focused empirical data?

We must start coaching and teaching both Software Craftsmanship and Product Craftsmanship - otherwise we will lead our clients to disruption.  Or perhaps Agile simply becomes irrelevant.

Digital Transformation Changes the Game

I was working with a large company that had started piloting a Digital Delivery model in one business line.  They had co-located the business, technology, and support functions.  The pilot was a success – the team had delivered improved product line performance in less than 6 months.  They had even trained the call center and created a marketing campaign.  However, the rest company continues to use old PMO model of percent allocating resources to projects.  They were delivering more projects than ever…but with increasing client attrition.   

The COO had called a meeting with his direct reports to discuss expanding the teaming model, but had gotten push back from his leadership team.  They said they communicated the urgency of client losses to their organizations, and that pulling people away from active projects would cause disruption and delays.  

Next he called a meeting with me and here's an except:

COO: I don't get it.  How am I going to convince these guys that we need to rapidly expand the team model so we can release full solutions out to our clients?  They all know we have a big problem with client attrition.  They tell me they are communicating urgency to their people, but the first pilot team released a solution that stopped client erosion – and they did it 10 months early. 

Me: Think of it like this: Most of your employees are experts and excellent at the jobs they have today.  They are like professional-level bowlers who are awesome at bowling strikes.  All day, they get a ball, they bowl strikes.  The more strikes, the more your leadership is rewarding them.  Leaders and management communicate urgency, everyone says “You got it, Boss!” and start to bowl strikes faster. Now you are saying "We are all going to start playing BASKETBALL!"

COO: But this is what I want.  I want teams that can deliver on a common goal, working together - getting solutions out to market for our business and for our clients.  We can't have individuals bowling strikes with no understanding of what is happening on the 'other lanes.'

Me:  Yes!  Here is what is happening on the ground, though.  We say: "Today, we are going to start learning how to play BASKETBALL" and we hear: "GREAT... but can I still use a bowling ball?  See, I already know how to use a bowling ball, and it’s still a ball.  I’ll even call it a basketball.” We explain that people get hurt when they try to catch a pass if you use a bowling ball, and the next question is “Well, can I at least stay in this alley, it has hard wood floors? It’s narrow, and I can put up bumpers if I want to –”.  This conversation slows down any move to model we used with the pilot team.

COO:  And now, by communicating urgency to their people, my leadership team has basically told everyone “Bowl Faster!”

This is a common scenario.  Though every organization may have a different structure or business model when they start, Digital Transformation must fundamentally change the game you are playing.  Messages that your leadership sends through the hierarchy (or rumor mill) can make or break employee willingness change the way they work.  

How many of your company goals can be met if your Leaders communicate the same rules they have for over a decade, but with more urgency?   The answer is NONE.  Your Leadership’s understanding of this fundamental concept, as well as the communication of it to the rest organization is imperative. 

…and sports analogy usually helps. :)

Inside Menlo Innovations - an Intro From an Ex-Menlonian

I was in start-ups and being somewhat of a road warrior.  My own start-up won an Inc. Web Award, I'd been to Dubai, and then I had to get divorced.  Without going into much detail, what it meant to me was that I had to do something to support my family that didn't mean weekly travel.

Enter Rich Sheridan, CEO of Menlo Innovations.  At this point I can't recall who made that introduction, but I do remember what they said: "you HAVE to have coffee with Rich!"  There's something about a combination of passion and story telling ability that makes Rich one of the more captivating people to talk to.  He met me and then invited me up to see Menlo...I was instantly in love with the place.  The walls were full of paper, the air was a-buzz with the chatter of innovation.  I couldn't help but want to be a part of it.

You can't just pass an interview with Rich to have the opportunity to work at Menlo.  You have to go through an "Extreme Interview,"  This means a cattle-call style interview, at night, with (in my case) over 40 other interviewees all in the same open space.  Rich introduces himself, welcome's everyone, and advises those there to get work: "your job is to get the other person hired."  After that, it's pairing with three different people on three different tasks all while being watched by three different "facilitators" who are already do work for Menlo.

As facilitators, you look for things like sense of humor, ability to share the pen, accept ideas from their partner?  Are they overbearing or do they listen well to their partner?  How do they do under the pressure of trying to get progress on an hour long task when they only have 20 minutes to complete it?  At the end of the night, when candidates leave, facilitators gather for dinner, pictures of interviews are projected on a screen, and the three who observed the tasks vote with thumbs (up, down, or middle for undecided.   If there isn't a consensus, discussion, sometimes very passionate and spirited discussion ensues.   Successful candidates progress.

Because all team roles pair at Menlo, the next step is to pair in with different projects in one day, then 3 days, then a week, then three weeks if you are successful.  With feedback all along the way.  Success means that you are generally back on the schedule every week - as long as client work remains. 

I was lucky to be on that schedule for almost 3 years in the late 2000's.  Lucky because it allowed me to learn Agile from soup to nuts, lucky because it enabled me understand how Innovation and Lean Start-up work as a system, and lucky to work with passionate and brilliant fellow Menlonians.  Personally, those were the roughest three years of my life, but professionally I still pull from that experience at least weekly to inform the way I think about my company, my clients, and my work.

In my next Menlo related post, I'll talk more about Menlo's process, in the meantime you can read Rich's book, "Joy".

Cross-Functional Demystified

I was speaking at a conference a few weeks ago and got a question about Cross-Functional Teams.  The way he asked the question, it was clear what he meant - he meant "how do I get QA to work with my development team?"  It may shock you to hear me say that having a SCRUM team of Developers and Testers does NOT mean the team is cross functional.  I'll explain:

In football you have catchers, running-back, quarterbacks, defensive lineman, etc.   If the opposing team fumbles the ball right in front of a lineman what does he do?  Stand there and say "Where are they guys who are supposed to run this ball?  I don't run the ball.  HELP!!!"  No.  He grabs the ball and runs as fast as he can...sometimes even being responsible for the game-winning touchdown.  That's what we mean by being cross functional.  How does this football player know what to do?   He knows it's his responsibility.  He knows the rules of the game.  In addition to his squad work, he works with the rest of the team on real plays in true game scenarios.

So what am I saying?  Have the SKILL SETS on the team is one thing.  Having people who are given permission to, expected to be and TRAINED TO BE cross-functional is something else.  Cross-Functionality isn't just a skill set it's a MINDSET that breaks silos across disciplines and hierarchies.  It has to be taught, recognized, and rewarded because it isn't easy.   The risk of not being cross functional?  Bottlenecks and your organizational "dropping the ball" in the market, losing to competition, and falling behind on the innovation curve.

Check back for a post about how incentives can help.