emag lean startup

Upload: rangel-torrezan

Post on 03-Feb-2018




0 download

Embed Size (px)


  • 7/21/2019 EMag Lean Startup


    LEANSTARTUPeMag Issue 6 - November 2013


    Minimum Viable

    Products for


    Enterprise software startups use a

    minimum viable product (MVP) to

    learn about customers with limited

    effort and money.

    PAGE 8

    Building Scalable

    Products that

    Customers Love

    Per Jonsson discusses Lean

    Startup in the context of real

    world examples, and helpful tools

    for startups.

    PAGE 10

    Interview with

    Brian Murray

    from Yammer

    about Lean Startupand using Minimum

    Viable Products

    PAGE 12


    YouBuildTDD was a revolutionary idea in the late 90s.

    Entrepreneurs practice a similar approach,

    they try to sell their product/service even

    before they build it. Naresh Jain explains his

    approach of nding effective MVPs.

    Page 3


  • 7/21/2019 EMag Lean Startup

    2/22Page 2Contents

    Sell Before You Build Page 3TDD was a revolutionary idea in the late 90s. Entrepreneurs practice a

    similar approach, they try to sell their product/service even before they

    build it. Naresh Jain explains his approach of nding effective MVPs.

    Minimum ViableProducts for Enterprises Page 8Enterprise software startups use a minimum viable product (MVP) to learn

    about customers with limited effort and money. How can organizations

    deploy lean startup principles to develop a viable product for their


    Building Scalable Productsthat Customers Love Page 10Per Jonsson discusses Lean Startup in the context of real world examples,

    and helpful tools for startups - Feedback Loop, Customer Development

    and the Lean Canvas.

    Interview with Brian Murrayfrom Yammer about Lean Startupand using Minimum Viable Products Page 12Brian Murray explains how Yammer uses Minimum Viable Products to test

    their business customer hypotheses, and why they focus so much attention on

    the architecture of their products.

    Managing Experimentation in aContinuously Deployed Environment Page 16Wil Stuckey explains how Etsy manages to deploy nearly ~10,000 changes in

    one year, and how they run A/B experiments in the midst of continual code


    Communicate Business Valueto Your Stakeholders Page 18Learn why and how to communicate benets rather than

    featuresand what it will mean for you, your team and your organization.


  • 7/21/2019 EMag Lean Startup

    3/22Page 3Contents

    Lean Startup / Issue 6 - November 2013

    Over the last four years of building my own startupsand involvement with various other startups, the mostimportant lesson Ive learned is Sell your product/ideabefore you build it. Seriously!

    During this journey, Ive met many successful foundersand their most important advice has always been Doyou have paying customers? If not, rst get them andthen think of building a product that addresses theirreal needs. It sounds to me, having been a test-driven

    development veteran, like Do you have failing testsbefore you write/modify any code?

    At Kickstarter, an impressive 44% of projects have mettheir funding goals before theyve started building aproduct. Applying this validation-driven approach tonew product/service development certainly soundsfascinating and desirable. I would love to momentarilypause time while people line up on my doorstepwaiting to pay me hard cash for a product that doesnteven exist. Its worth a shot, right?

    At Edventure Labs, when we started validating ouridea of teaching ve-year-old kids scientically provenmental arithmetic skills, which lets them calculatefaster than a calculator, we realized our potentialcustomers (parents of ve-year-olds) only vaguelyunderstood the problem we were trying to solve. Tothem, it was about number crunching, which is anobsolete skill replaced by electronic gadgets. To makematters worse, they believed kids had to be borna genius to calculate faster than a calculator. Theydid not know if their kids were capable of or eveninterested in acquiring this skill. We simply could notget any real feedback from talking to parents. If wetried to sell them our product (an educational gameto teach mental arithmetic), they would immediately

    change the topic as if wed uttered some taboo.

    We had to gure out how to have a meaningfulconversation with our potential customers. We couldhire a world-class team, build the product, hire somekids to go through our educational program, and thenshow real data to the parents to prove the importance/feasibility of our product. However, existing teachingmethods take a minimum of 10 minutes of practiceevery day for 18 months to teach a kid this skill. A

    good 70% of the kids drop out of these programs.Moreover, we had no clue what the product will be.Also, we had to zero in on the technology, the teachingand evaluation techniques, etc. This would easily takeanother six months. So we were looking at a minimum24-month horizon, assuming we knew exactly whatneeded to be done, before we could actually havethis conversation with parents and acquire payingcustomers.

    If I were a typical agile product owner, I would say, Its

    a very high-risk project. Its best to skip it. Howeveras startup founders, we were convinced that thiscould change the world and hence the risk was totallyworth it. In fact, we told ourselves that because itsso hard, no one else had yet solved this problem orbuilt a successful product. So lets go full swing, hire ateam, do a collaborative product-discovery workshopwith them, come up with a release roadmap, and startsprinting. That was absolutely the best and fastest wayto burn all our funds and destroy our dreams.

    Instead, we ran a series of experiments to answer openquestions and through this process completely renedour strategy and our product. Over the last two years,our vision has remained the same, but weve done ninesignicant pivots and nally we feel weve nailed it.

    Sell Before You BuildBy Naresh Jain

  • 7/21/2019 EMag Lean Startup

    4/22Page 4Contents

    Lean Startup / Issue 6 - November 2013

    First, we had to gure out an effective teachingtechnique for ve-year-olds. We wanted real data asa baseline to validate the retention power of differentteaching techniques. We picked the introductionto abacus (one of the tools we use to teach mentalarithmetic) lesson. Quickly, we put together a storyline,wrote a script, hired a professional animator, got a

    person in the US for the voiceover, and produced a33-second animation that introduced the abacus.

    We got a bunch of kids to watch this animation

    and afterwards asked each to represent different

    numbers on the abacus. Fewer than 50% of the kids

    were able to do this. We quickly realized that kids

    have so short an attention span that they quickly zone

    out unless they are able to interact with what they see

    on the screen. Animations are expensive to create andrequire a lengthy turnaround even for small changes.

    It was clearly a bad strategy.

    Inspired by mobile games, we came up with a

    hypothesis that if we created inline instructions and

    used micro-simulations, the kids would have a better

    retention and be able to learn better. To quickly test

    this hypothesis, we found a bunch of images on the

    Internet within 10 minutes, created a presentation,

    and added transitions to create an animation effect.Then we exported this presentation as a movie.

    The kids could watch this 10-second movie and follow

    a simulation/inline instruction in our game. Once the

    simulation showed how to represent a number, we

    would ask the kid to copy that the abacus. Of course,

    the kids could not move the on-screen beads but we

    would be able to test whether the kids tried to move

    the right ones and assert if they remembered how

    to represent the number. Ninety percent of the kidscould. If they could, we would ask them to represent

    other numbers not shown in the simulation to see if

    they could extrapolate what they just learned and

    apply the logic to other numbers. Most kids could do

    simple numbers, but were not able to do numbers

    that involved the upper bead. This was another good

    lesson from this experiment.

    Another major question we had to gure out was

    our distribution strategy. Would we be able to sell

    our educational game as an app in the app stores? To

    test this, we quickly created two small abacus games,

    Abacus Rush and Abacus Ignite. Rush was free and

    Ignite was paid. We wanted to see how paid apps

    performed compare to free apps in our segment. Howmany free app users would pay for the paid app? We

    gured 10% conversion would be great. We quickly

    learned that paid apps would not help us sustain

    our product development. Free apps did fairly well.

    Could we use free apps as a marketing tool to nd

    distributors/partners? We launched Abacus Rush in

    Google Play as a free app called World of Numbers.

  • 7/21/2019 EMag Lean Startup

    5/22Page 5Contents

    Lean Startup / Issue 6 - November 2013

    To our surprise, we crossed 120K downloads in

    a weeks time. All wed done was hack something

    together to test our hypothesis. We had allowed any

    Android device to download the app and we quickly

    realized the app had performance and usability issues

    on lower versions of Android. We had to pull it off

    the app store to avoid damage to our reputation.We then invested a week to x those issues and

    launched another game called Number World.

    Despite not allowing outdated versions of Android

    to download the app, we got 93K downloads in four

    days. These quick experiments helped us get the kind

    of partnership offers we were looking for. Its a classic

    example of how cheap, safe-fail experiments helped

    us to validate our hypothesis and make progress in

    our product strategy.

    Previously, potential partners would commonly look

    at our concepts and tell us, This is too futuristic. This

    will not work! The 120K downloads certainly helped

    us change their mindset.

    I can go on with many other experiments we ran to

    validate our hypothesis and gure out our product

    strategy, but let me step back and quickly recap whatwe learned and explore how you can use some of

    these techniques.

    As startup founders, we might have a knack of

    identifying real opportunities or pain points,

    but building a sustainable business around it is

    a whole different ball game. It requires a ton of

    experimentation to gure out how to package and

    pitch your product to really appeal to your target

    customers. For many years, startups primarilyfocused on building their dream products. They

    probably spent time creating a business model, but

    mostly ignored customer development (acquisition

    and retention). Figuring out a sustainable business

    model is exponentially harder than building the

    product itself, yet founders and product owners dont

    pay as much attention to customer development as to

    the product.

    What startups really need is a scientic frameworkfor conducting many safe-fail experiments. In lean-

    startup lingo, lets say you have an idea or a vision for

    a product or a service. You devise a series of possible

    strategies you could use to full your vision. It is

    important to acknowledge that each strategy is based

    on a list of hypotheses that need to be validated using

    a series of cheap, safe-fail experiments (via MVPs) to

    obtain validated learning. Then, based on real data,

    we pivot or persist the direction of the vision. Either

    way, you need to constantly keep running a series ofexperiments with fast feedback cycles to calibrate/

    validate your progress/direction.

    MVP is a safe-fail experiment. The best MVPs are

    those that give you maximum validated learning for

    minimum investment (time, effort, and opportunity

    cost). In other words, life is too short to be wasted

    building products that no one wants.

    This is the lean-startup movement in a nutshell.

    Business Facing

    Technology/Implementation Facing

    Are we building the right product?

    Are we building the product right?

  • 7/21/2019 EMag Lean Startup

    6/22Page 6Contents

    Lean Startup / Issue 6 - November 2013

    Agile methods are really good at addressing the

    second question. To some extent, they also help you

    answer the rst question; however, there is certainly

    a delay in getting that feedback. Typically you get that

    feedback at the end of your rst iteration/sprint and

    in some cases only during your rst release.

    Getting this feedback in a few weeks or at most three

    months is certainly better than getting feedback a

    couple of years later like in traditional methods. But

    startups, which operate under high conditions of

    uncertainty, might not be able to afford this delay.

    More importantly, the lack of focus on cheaply and

    safely validating whether we are building the right

    product and, if not, then pivoting is essential. And

    agile methods dont really focus on solving this

    problem. In general, building something quick anddirty for experimentation with real customers is

    something many agile folks look down upon.

    If you think about it, agile methods ourish when

    your users are locked in. Agile methods give you

    opportunities to build a healthy relationship with

    your (known) customers. Via ongoing collaboration,

    communication, and feedback with them, the team

    gains a better understanding of their needs or pain

    points. But when your users are not captive, theydont really know or recognize their pain points,

    especially in end-consumer facing products, and

    relying completely on your product owner and using

    agile methods seems like a bit of shooting in the dark.

    Its a gamble!

    I remember sitting at a bar in downtown Chicago in

    2007 and discussing this issue with Jeff Patton. Jeff

    drew the following diagram on a napkin:

    Quadrant 1 seems like a natural habitat for agile

    methods. As you travel out in the wild, however, you

    might need additional techniques to succeed. This

    might explain why product companies are not really

    seeing the benets they expected from agile methods.

    Jeff was one of the pioneers who spotted this

    gap in agile methods and tried to ll it with user-

    story mapping and, later, product discovery. The

    collaborative nature of these product-discoverysessions and their focus on minimum marketable

    product (MMP) is an important next step for many

    agile teams.

    The lean-startup community really pushed the

    envelope on a scientic approach to running a series

    of safe-fail experiments. Lean startup also focused

    heavily on customer development and business-

    model validation, which agile methods completely

    missed. It was mostly left to the product owner tosolve these complex puzzles.

    This is just the beginning of a new era of scientic

  • 7/21/2019 EMag Lean Startup

    7/22Page 7Contents

    Lean Startup / Issue 6 - November 2013

    experimentation in the product-development

    space. Im pretty excited to see how lean-startup

    principles and thinking are already penetrating large


    For example, with lean-startup, many enterprises are

    treating each new initiative at a portfolio level justlike a startup. They are running parallel cheap, safe-

    fail experiments on multiple initiatives and nally

    choosing the most promising initiative instead of

    picking one initiative right at the beginning based on

    personal preference or gut feeling.

    Last time I visited a large energy company, I heard

    one developer ask the product owner in the planning

    meeting what was the hypothesis behind a new

    proposed feature. This was a powerful question.Immediately, the focus shifted from Lets build as

    many features as possible and see which one sticks,

    to What is the bare minimum we need to build to

    obtain validated learning before we decide which

    feature to invest in. This is brilliant because it will

    really help teams to build crisp enterprise software

    instead of these bloated monsters that are a real pain

    in the neck for everyone to deal with.

    Continuous deployment is another practice thatenterprises are trying to embrace. It makes absolute

    sense for enterprises to be able to quickly validate

    their new feature direction without having to build

    the whole damn thing only to realize only 3% of their

    users use that feature. It feels like a nice progression

    from CI and other agile practices that organizations

    are already practicing. Continuous deployment also

    helps enterprises to use techniques like A/B testing

    and stub features, which let the product owner make

    concrete prioritizations based on real data.

    The good news is that lean startup has something to

    offer to everyone, whether you are a startup trying

    to bootstrap yourself or a large enterprise building

    mission-critical applications.

    About the AuthorNaresh Jain - Tech-startup founder and agile/

    lean evangelist

    Naresh Jain is an internationally recognized

    technology and process expert. As an independent

    consultant, Naresh worked with many Fortune

    500 software organizations and startups to deliver

    mission-critical enterprise applications. Currently,

    Naresh is leading two tech startups, which build

    tablet-based adaptive educational games for kids,

    conference management software, and a social-media

    search tool. His startups are trying to gure out thesecret sauce for blending gamication and social

    learning using the latest gadgets. In 2004, Naresh

    founded the Agile Software Community of India, a

    registered non-prot society to evangelize agile, lean,

    and other lightweight methods in India.

    READ THIS ARTICLE ONLINE ON InfoQhttp://www.infoq.com/articles/sell-before-you-build

  • 7/21/2019 EMag Lean Startup

    8/22Page 8Contents

    Lean Startup / Issue 6 - November 2013

    The purpose of a minimum viable product (MVP),

    as dened by Eric Ries in lean startup, is to expend

    limited effort and money to learn about customers

    . In the blog post The Problem with a Lean Startup:

    the Minimum Viable Product, online marketer

    Paul Kortman shares his experiences developing a

    minimum viable product. He starts by explaining what

    lean startup is:

    The basics of the lean startup philosophy are to get user

    feedback, do user testing, and discover if people are

    willing to use (and pay for) the product you are creating

    both before and throughout the creation process.

    Lean startup intends to make and organization more

    efcient by quickly nding out if there is a need for a

    product that it wants to develop. But organizations

    sometimes nd it difcult to dene a minimum viable


    We all understand what Product means, and

    Minimum makes sense: what is the bare essentials

    that you can get away with?

    Paul describes the questions the team had while

    trying to develop a minimum viable product:

    At what point does our product become viable?

    When we reach critical mass?

    When we have no other features to build? (thatllnever happen, Im a visionary dont you know)

    When we bring in revenue?

    When we make prot?

    In the Forbes article The Times Are Changin:

    The Evolution of Enterprise Software, the

    director of enterprise strategy at Yammer,

    Brian Murray, describes what is changing in the

    development of enterprise software with lean startup,

    and why these changes are necessary:

    A rampant inefciency in traditional enterprise

    technology development is the attempt to build the

    perfect product before its released to customers....

    Development teams are now focusing on building

    MVPs whenever possible.... This allows service

    providers to efciently test their hypotheses

    and ultimately create a product that slowly and

    continuously evolves into what it should be, not what

    people think it should be.

    In the blog post Minimum Viable Product vs

    Minimum Delightful Product, Adam Berrey gives his

    view on how a enterprise minimum viable productlooks:

    ...An enterprise business system will usually win on

    underlying technological innovation, features, and

    sales/marketing. If you can get just enough features to

    start selling, then you have something viable. Youre

    off and running.

    Jesus Rodriguez explains in his blog post The

    Enterprise Minimum Viable Product: Focus onViable Instead of Minimum how enterprise software

    development is different from consumer product

    development when it comes to minimum viable

    Minimum Viable Productsfor EnterprisesBy Ben Linders

  • 7/21/2019 EMag Lean Startup

    9/22Page 9Contents

    Lean Startup / Issue 6 - November 2013

    products. In the consumer market, the user of the

    software is also the buyer. This is rarely the case in the

    enterprise world, which challenges getting product


    ...The people trying the MVP are rarely the ones

    making the ultimate purchase decision.... Enterprisesoftware startups need to be able to carefully

    evaluate the feedback received from an MVP, ltering

    the noise from the features that will make the product

    more relevant to potential customers.

    Another challenge for the concept of minimum viable

    products for enterprise software is how organizations

    base buying decisions on functionality. Jesus

    Rodriguez calls this overfeature culture:

    For decades, enterprise software has evolved in the

    middle of a culture that value the number of features

    over the simplicity and usefulness of a product.

    By presenting an MVP version of your product to

    enterprises, you might run onto a wall of prejudices

    that tend to associate the number of features in a

    product with its robustness and enterprise readiness.

    Sam Palanis blog post Lessons from Agile The

    Minimum Viable Product describes why they used

    the minimum viable product for a complex enterpriseinitiative:

    Yes, we were bringing in tons of data and writing really

    complex ETLs and interfaces to extract and manipulate

    the data, but the actual business functionality was

    getting released in future releases and further planned

    out sprints. In an ideal world we still would have been

    able to succeed with our current planned approach,

    however in the real world we could sense the risk of

    our stakeholders patience running out.

    He explains how he sees a minimum viable product,

    and how you can use that to develop and deliver a

    minimum desirable product:

    A minimum desirable product goes beyond

    viability to include more scope and features from

    the requirement or scope document. Ideally you

    should plan a agile release or sprints with a MVP

    progressively moving to the MDP state in the nextiterations that would deliver maximum business

    benet and customer delight.

    Sam describes a ve-step process to identify and

    dene an enterprise minimum viable product.

    The steps are identifying stakeholders, scoping,

    dependency between features, prototyping, and

    aligning the minimum viable product with the

    business needs. Step three is about the product


    Limit the number of interdependent features that you

    include in your MVP. Focus on the viable, but keep the

    minimum in mind. Having too many interdependent

    feature will limit your ability to do so.

    About the author

    Ben Linders is a senior consultant in quality, agile,

    lean, and process improvement, based in the

    Netherlands. As an advisor, coach, and trainer, he

    helps organizations by deploying effective software

    development and management practices. He

    focuses on continuous improvement, collaboration

    and communication, and professional development

    to deliver business value to customers. Ben is an

    active member of several networks on agile, lean,

    and quality, and is a frequent speaker and writer. He

    shares his experience in a bilingual blog (Dutch and

    English) at www.benlinders.com and on his twitterpage @BenLinders.



  • 7/21/2019 EMag Lean Startup

    10/22Page 10Contents

    Lean Startup / Issue 6 - November 2013

    Building Scalable Productsthat Customers LoveBy Per Jonsson

    At the GOTO Copenhagen 2012 conference, Per

    Jonsson discussed lean startup in the context of

    real-world examples and helpful tools for startups:

    feedback loop; customer development; and the lean


    Per started his presentation with his teams startup

    concept in the application hosting space. It was a

    learning experience. The problem, Per explained, wasthat they were young, passionate, and full of energy.

    They had one of Swedens best programmers, and

    they were two business engineers thinking theyre the

    best in the world. They had passion but were running

    in circles. And that was painful for them because they

    wanted to get somewhere. Why didnt it work?

    And then they met Emil Eifrem, the CEO and founder

    of Neo4j. Emil told them that they needed to focus

    and told them about minimum viable product. Buthe also made clear they were running a web startup,

    where nine out of ten fail. Why do they fail in the rst

    place? Is it technology? No its not. They self-destruct,

    Emil called it. Startups get overly ambitious. They

    waste energy and resources on the wrong things.

    They do too many things.

    Per mentioned to the audience what they learned

    they should never have done:

    Dont write a business plan.A lot of people, especially

    scientists or those heavily theoretical, always start

    with documents. The problem with any document

    is that as soon as youve written it, its by denition

    obsolete because the market is always changing. So

    youre sitting there with this huge document in which

    youve invested a lot of time and energy but it doesnt

    provide output. A quote by Steve Blank says that a

    business plan is something you give to an investor so

    they can put it on a shelf and never read it.

    Ive talked to a few investors who said, This is whatwe do. We actually said no to many startups because

    the rst thing they did was to send us a business

    plan..... We did because it just felt as if they were not

    out talking to the customer, as if they were in their

    own mind somewhere.

    Dont make assumptions.This is extremely hard

    when youre a founder with, as most founders,

    lots of ego. Entrepreneurs, in general, VCs, board

    memberseverybody wants to have their opinionin there. People want to give advice; they feel like a

    better person for doing so. A company of individuals

    all wanting to say something and have an opinion is a

    problem. In the end, every opinion is just taking you

    further from the real truth. Everything is a guess.

    Somebody with 20 years of experience can make a

    very, very good guess but its still a guess. Every guess

    needs to get validated. You need to go out there and

    talk to people and see if your case is true. Is it still

    true? It might have been true a week ago or a year ago,but is that still the case?

    Per showed how the lean startup model resembles

  • 7/21/2019 EMag Lean Startup

    11/22Page 11Contents

    Lean Startup / Issue 6 - November 2013

    agile development. You have iterations or you

    iterate on something. The difference here is that

    you integrate the customer-feedback loop into the

    validation. Every time you have an iteration, you start

    with an hypothesis, for example, I think if we write

    this blog post, it will get us at least 100 subscribers.

    And then when you have your hypothesis, you needto test it. To test it, you need to have a prototype of

    some sort.

    The lean startup is all about minimizing waste, said

    Per. There are two types of waste that are common.

    One is overproduction, doing things you dont need,

    doing the wrong things, or building a product that is

    too big. The other is inventory: you build something

    immediately because youre going to need it later

    and your team is passionate about building it. But ifyou dont need it now, why build it now? It creates

    complexity in the product before its necessary.

    At the beginning, look for your minimum viable

    product. You want to have the minimum product,

    meaning with as few features as possible, but it needs

    to be viable. You need to test from the beginning that

    people want to pay for your product. If you have a

    minimal product but people dont want it, you have a

    problem. There has to be a willingness to pay.

    The discovery phase is all about the problem and

    the solution. When you have that, you can look at

    the market and ask, Okay, how can I create a sales

    process for this product that I can repeat over and

    over in the same market and succeed? Is this market

    big enough for that? How can I not go out to every

    customer and sell? How can I make it scale?

    Per explained that this is where you often have to goback and say, No, we were wrong here. The market

    were looking at is too small and its not growing. So

    were not going to choose that market. We have to go

    back. That is what it called a pivot. A pivot can be that

    the market is too small. It can be that your hypothesis

    was actually wrong. It can be that you need to focus

    on a subset of the existing product or even a new

    product. In the end, its about the fact that you cant

    go on because if you go on the next step, it gets really

    expensive. If you go here without knowing thesethings and start the company, you burn a lot of money

    and thats when VCs get really angry with you.

    The center of the validation process is nding your

    business model, said Per. Osterwalder and the

    business-model canvas are quite popular. The lean

    canvas is an adaption of the business-model canvas

    for the lean startup. Its focusing more on early-stage

    companies, basically. And in the beginning, you want

    to focus on problem solution because thats yourdiscovery phase then.

    Per ended his talk with some suggested readings

    about lean startup:

    The Four Steps to the Epiphany by Steve Blank

    The Lean Startup by Eric Ries

    Lean Entrepreneur by Brant Cooper and Patrick


    About the speaker:

    Per Jonsson is a Swedish entrepreneur and engineer

    passionate about creating technology that simplies

    lives. Per is at a focal point for global impact as

    the Stockholm ambassador for Sandbox Network

    and as the CEO and co-founder of Omnicloud, a

    next-generation Platform-as-a-Service. Through

    Omnicloud, he is also an active contributor to the

    open-source PHP framework Melt.

    Presentation Summary by Ben Linders.



  • 7/21/2019 EMag Lean Startup

    12/22Page 12Contents

    Lean Startup / Issue 6 - November 2013

    Interview with Brian Murrayfrom Yammer about Lean Startupand Minimum Viable ProductsBy Ben Linders

    Enterprises are nding ways to adopt the lean

    startup approach to support the businesses and

    customers to whom they deliver their products. They

    want early and frequent customer feedback to be able

    to understand their needs and deliver products that

    create value for them.

    The news item Minimum Viable Products for

    Enterprises gives some examples of how enterprises

    can use lean startup with limited effort and money

    to learn about customers. One of the companies

    mentioned was Yammer, and InfoQ talked with Brian

    Murray, Yammers director of enterprise strategy,

    about how the company uses minimum viable

    products to test their business-customer hypotheses,

    and why they focus so much attention on the

    architecture of their products.

    InfoQ: Brian, can you briey introduceyourself to the InfoQ readers?

    Brian: Ive been with Yammer for about three

    years now, and before Yammer I was a technology

    consultant rolling out big technology like SAP and

    Siebel in large enterprises. I made the shift over to

    Yammer, and Ive had a really incredible experience

    learning about software as a service, cloud, and new

    ways of introducing technology. I spend about half

    my time at Yammer on the customer-engagement

    side, helping companies make sense of this new way

    of communicating, and the other half on the product

    team helping shape the direction of our product and

    evangelize and explain this new way of creating our

    product and iterating on it rapidly.

    InfoQ: Would you describe your role

    as also a product manager?

    Brian: Yes. Our product team is split into two

    categories. We have the design category and

    those are all our user researchers, user-experience

    designers, and the pure creative designers, so they are

    the ones creating the look and feel of Yammer.

    The other category is pure product management,which includes all the product managers who are

    responsible for bringing new features to market

    and working with engineers, our analytics team,

    the design team. And there is my team that is sort

    of a liaison between the market, our customers, our

    internal teams like sales and customer engagement,

    and the technical teams like engineering and

    analytics. Our job is to make sure that what we are

    building is going to be well-received by the market

    and our customers, and that we are anticipating andmitigating any potential obstacles.

    InfoQ: How big is Yammer right now?

    Brian: Yammer has about 450 employees now,


    InfoQ: In an article last year in Forbes (mentioned

    in the InfoQ news item Minimum Viable

    Products for Enterprises), you mention that a

    new approach is needed to develop and releaseproducts quicker. What makes this so important?

    Brian: This new approach that we call rapid iteration

    - there are a lot of different terms for it - should be

  • 7/21/2019 EMag Lean Startup

    13/22Page 13Contents

    Lean Startup / Issue 6 - November 2013

    adopted by all technology vendors for a number of

    reasons. The primary reason is that its available now.

    Historically speaking, when the Internet was not as

    powerful, when applications were purely on-premise

    models, it just wasnt possible to have a software-as-

    a-service model. However, with the introduction of

    cloud architecture, we can make changes quickly toour products and ultimately avoid making too many

    assumptions, and thats key here. In a traditional

    enterprise-development model, you would have two-

    or-three-year release cycles and you would have to

    make a lot of assumptions as to what your users were

    going to expect from your technology by the time it

    was released to market.

    With Yammer we make small assumptions. We have

    hypotheses and we are able to test them quicklyover weeks instead of months or years, and that way

    we can steer our ship and make sure that Yammer is

    directionally meeting the needs of our customers and

    that we are not working on something or delivering

    a feature that is ultimately not going to achieve the

    value that we are trying to create.

    InfoQ: Yammer is applying the lean-startup

    approach. Why did you choose this, and howdid you implement it at Yammer?

    Brian: We chose it because it was available. If you

    look at the pedigree of our founding team, with David

    Sacks and Adam Pisoni, they had a lot of experience

    in technology, but in consumer-focused technology,

    not necessarily enterprise-focused technology. And

    so, they were well-versed in the cloud model, with

    lean-startup approaches, with multitenancy, and they

    believed wholeheartedly that these architectures

    where inherently better, more efcient, and allowedthe company to scale faster. We use the same technical

    architectures and development methodologies in this

    enterprise context - which has had some interesting

    implications - but overall, it really, in our opinion, was

    what made Yammer, Yammer. Its what allowed us to

    compete when we were just starting up and its what

    allowed us to offer unique perspective and experience

    that Microsoft is getting a lot of value from. You may

    often hear our founders saying that architecture is

    destiny; we really do believe that in the long term,

    the way your technology is architected dictates your

    sustainability and long-term viability.

    InfoQ: Minimal viable products (MVP) are

    used to deliver light versions of new features

    of Yammer. Can you give some examples of

    how this has been used?

    Brian: We almost always try to employ an MVP model

    in our feature set. This isnt to say that we release half-

    baked features, but that we have hypotheses as to whatour users are expecting, what they are looking for in our

    products, either through customer feedback or looking

    at overall engagement data. We may have a grand vision

    for what our customers are looking for, but rather than

    trying to build an entire feature set that encompasses

    that vision, which would take a lot of time, we break it up

    into smaller chunks.

    An interesting example of this is a new feature that

    is called Universal Publisher. Universal Publisher

    represents a really signicant change in Yammer. (It lets

    you) post a single message to multiple groups at the

    same time. Today, you can only post a single Yammer

    message to a single group and our back-end systems are

    architected to support that use case. With Universal

    Publisher, we want to enable multi-group posting and

    multi-audience posting, but what that means is making

    signicant changes to our messaging architecture.

    Rather than building our complete vision for this

    feature, we are breaking it up into small pieces: small

    improvements to the UI, gradual message architecturerenements, etc. By breaking up our vision into smaller,

    more manageable chunks, we are able to make fewer

    assumptions and learn whats resonating with our users

    along the way.

    InfoQ: I can imagine if you look at public and

    private groups, youre going to be balancing

    between privacy on one hand and ease of use

    on the other hand?

    Brian: Yes, and also how do you visually indicate

    that a message is part of a private group and a public

    group, or how do you make it clear to the end user

    that when they are posting something its either

    private or public? We have some ideas about what

    might work but we cant say with certainty that one

    implementation of that idea is better than another, so

    thats where we will use our MVP model and rapidly

    iterate on the idea until we get it right.

    InfoQ: Do lean-startup practices and an MVP

    approach to product development differ in

    the enterprise context? If so, how?

  • 7/21/2019 EMag Lean Startup

    14/22Page 14Contents

    Lean Startup / Issue 6 - November 2013

    Brian: Again, my past experience before joining

    Yammer was rolling out traditional enterprise

    technologies, large ERP systems, CRM systems,

    and these projects would take a year if not more.

    Part of that was the change management in the

    communication and the training involved in rolling

    out the new technology to make sure it was adopted.

    You have a specic and predictable go live date intraditional enterprise-technology deployments which

    the deployment team orients themselves around.

    In a SaaS environment, where you can continuously

    improve your product, the change is smoothed out

    over time. There is a major implication of this shift

    in technology deployments in the enterprise. The

    products we use in our daily lives like Facebook,

    Twitter and Zynga are changing twice a day now - but

    no one notices! Thats because the change is less

    charging and more gradual.

    Consumers also have a one-to-one relationship with

    the vendor creating the technology. With Yammer, we

    are selling to businesses, so we create relationships

    with the business and the teams running their

    Yammer network and they are representative of all

    the Yammer users in their network. When we make

    changes to the product, especially ones that are going

    to be noticeable or may alter the user experience, we

    need to make sure we are providing enough advancedcommunication so that our champions and our

    administrative teams on the customer side are fully

    aware of the change and implications. We also want

    to conrm they have all the training materials that

    weve created at their disposal so that they can ensure

    that this new feature is adopted effectively. This is not

    to say that these practices should not be employed;

    they absolutely should, but in an enterprise context

    you need to take a little more caution rolling out new

    changes because a lot of businesses are depending onthese tools for their day-to-day operations and you

    need to make sure you are not being too disruptive.

    InfoQ: I understand that its not just about

    the feature but also about additional

    communication and any means that are

    needed to implement the new features in the

    organization. These are part of your product

    and supplied to your customer, right?

    Brian: Absolutely. One of the differences from the

    traditional model is that with one-to-three-year

    release cycles, once you get the new version of the

    software, it is a drastically new application. There

    are a lot of changes that have been bundled up into

    this new version. On the other hand, with the rapid-

    iteration approach, you can actually smooth out the

    changes over time, rather than having a completely

    new experience at the time of upgrading your

    software. This enables a more natural transition intoan improved experience over time. Its about breaking

    down big ideas into smaller, more consumable chunks

    and introducing those in a way thats not disruptive.

    Ultimately, we are ensuring that the features that hit

    the market are valuable and are lifting core metrics

    like engagement, technology adoption, and message

    posting. With traditional software development, you

    had to make a lot of guesses as to what will work and

    theres no good way of validating those guesses once

    the new technology has been released.

    InfoQ: Testing your hypotheses and increasing

    customer understanding are often why

    companies use MVPs. Are there other benets

    from using the lean-startup approach?

    Brian: There have been a lot of interesting lessons

    that have come from the way we organize the product

    and engineering teams. Every team thats working on

    a feature includes the engineers that are building the

    feature, the designers who are designing the UI of

    the feature, and data analysts. Our analysts evaluate

    the engagement data on new features and then work

    with the product manager to deduce whats working

    and whats not working. One major benet is that

    the feedback loop helps our product managers make

    better and better hypotheses over time because they

    see whats resonating with our customer base. They

    get better at avoiding assumptions and keeping an

    open mind to all possible solutions.

    InfoQ: What did you learn from using lean

    startup? What worked, what didnt, and why?

    Brian: Our early architectural decisions were

    critical to our long-term success. Yammer is actually

    a compilation of a number of different services.

    Search, ranking, message feeds, proles, and more

    are all powered by separate services. All these

    services interact with each other to power Yammer.

    Rather than have a monolithic codebase, Yammers

    is distributed. This allows us to improve any one of

    these services independently, so we can enhance

  • 7/21/2019 EMag Lean Startup

    15/22Page 15Contents

    Lean Startup / Issue 6 - November 2013

    one service without worrying too much about what

    the trickle-down effect will be on everything else.

    Weve learned that by decoupling the services that

    power Yammer, we are able to innovate faster. In fact,

    weve spent a lot of energy taking some of our larger

    services, like the one powering Yammer feeds, and

    breaking them down into smaller services. By doingthat, we are able to again optimize more efciently

    without disturbing other services or the overall user


    InfoQ: How did lean help you with

    architecture? Did it make you more aware of

    the criticality of architecture?

    Brian: It helped us realize that there is a signicant

    advantage in being able to improve these different

    services individually. Lean helped us realize thatdecoupling or distributing our codebase is always a

    good thing, and the more we can do that the quicker

    we can move and innovate on Yammer.

    InfoQ: If companies would like to use lean startup,

    what you would want to recommend to them?

    Brian: I would recommend spending a lot of time

    thinking about your architecture (before you start

    building) and get a clear picture of the customers

    youll be selling to. If you are selling to the enterprise,consider the various regulatory environments, your

    customers appetites for change, and how you will

    create sustainable relationships with them. If you

    can plan ahead for that, you will be better off in the

    long term. Keep in mind that there is no end date

    to a good product. You should always be iterating

    because the demands of your market and your

    customers will always be changing. The pace of

    change is accelerating, so your product (and company)

    will always need to be evolving to meet that evolvingdemand. Its important to keep that in mind and to

    realize that this is all a journey. It comes down to

    building a product that your end users really love and

    helps them do their jobs better.

    InfoQ: Did you use any lean-startup camp or

    anything like that to get an understanding of

    lean startup?

    Brian: A lot of people have been very involved in

    that movement for a long time. Everybody has readliterature on this topic. Weve just employed those

    practices over time; its always been in the back of our

    minds. We dont consider it an option, more of a core

    principle that we all need to adhere to. Its been really

    great to have a founding team thats so committed

    to this philosophy and its fantastic to see more and

    more enterprise software vendors adopt these ideas

    as well.

    InfoQ: Is there something you personally

    learned from doing lean startup?Brian: What has been really interesting about this

    whole process for me -- moving from traditional

    enterprise technology to this cloud-based, rapid

    development approach -- is that we always have to

    remain intellectually honest. As a product manager,

    being intellectually honest means not tying your

    emotions to the particular feature youre working on. To

    truly deliver the best product to your users, you have to

    be open to the fact that you might be wrong and realize

    that the best way to measure your features utility is

    to look at the data collected through testing. Human

    judgment is imperfect and, as a result, we always should

    use data to help guide us towards the right decisions.

    Thats been a fascinating learning for me.

    InfoQ: So basically stay open for any input

    you get from your customers?

    Brian: Yes. Consider this: if you have engineers whose

    jobs are tied to a certain feature set, they will always

    want that feature set to take precedence over other

    features because they have a connection and an

    implicit need for that feature set to be highlighted or

    improved upon. But if you separate the team from any

    individual area of your product, you are able to make

    more rational decisions that are not inuenced by

    emotion or some other obscure motivation that is not

    really in alignment with the ultimate goal of improving

    the end-user experience.

    About the IntervieweeBrian Murray is director of enterprise strategy at

    Yammer, where he helps shape the companys product

    strategy to meet enterprise demands and evangelize

    SaaS, consumerizaton, and data-driven-development

    trends. Brian partners with customers across

    industries, geographies, and sizes to forecast changes

    in the market and promote adoption of Yammer and

    other SaaS-based enterprise applications.

    READ THIS ARTICLE ONLINE ON InfoQhttp://www.infoq.com/articles/brian-murray-lean-startup

  • 7/21/2019 EMag Lean Startup

    16/22Page 16Contents

    Lean Startup / Issue 6 - November 2013

    Managing Experimentation in aContinuously Deployed EnvironmentBy Wil Stuckey

    Wil Stuckey explained at QCon New York 2013 how

    Etsy manages to deploy nearly 10,000 changes in one

    year and how they run A/B experiments in the midst

    of continual code change.

    Etsy classies their website launches into three

    distinct groups: experiments; ramp-ups; and

    communications. Experiments are basically A/B

    tests, a way of validating a hypothesis. In a ramp-up(also called an operational ramp-up), Etsy releases

    a particular feature in a percentage of people over

    time to validate that it doesnt bring down the site.

    Communication is a catch-all bucket for things that

    arent necessarily code-related, like marketing.

    The cong system at Etsy works with branching in

    code and not with feature branches in the version

    management, Wil explained. This helps to ne-tune

    who gets to see what:

    How does a typical launch cycle look in the

    continuous deployment world? It starts the

    same, with an idea, for instance, on how to make

    the homepage better. But during the design and

    development cycle, it gets different, said Wil, as there

    will be multiple deploys to the website. They could be

    just renements to the code that xes bugs or could

    mean a conguration change that Etsy is opening up

    for a new set of people.

    One of the rst things Etsy does is an internal admin

    launch, where the staff can see the feature. It is

    used to gather feedback and to test the feature in anaudience slightly wider than the development team.

    The next step is called a public prototype. That is a

    group on Etsy that either invites members or is public

    for anyone to join. Users are asked for feedback,

    which is incorporated into the product. This goes on

    until the point when its ready for an experiment.

    An experiment has a hypothesis, e.g. an expected

    increase of user engagement. Fifty percent of eligible

    public trafc will receive the new feature and 50%

    will retain the old feature. After a few weeks, there is

    enough data to analyze and Etsy can decide whether

    or not to launch the renement.

    Wil showed that initially Etsy used a wiki and email

    to communicate changes and results of experiments,

    but this became overwhelming as the number of

    launches increased. To solve this, Etsy made a tool

    called Launch Calendar. It is a simple web app, written

    in Python and hosted on App Engine. It collectsstructured metadata about launches in a central

    repository where people can nd whats upcoming,

    whats current, and what is past:

  • 7/21/2019 EMag Lean Startup

    17/22Page 17Contents

    Lean Startup / Issue 6 - November 2013

    Etsy used Launch Calendar to send a daily emailupdate to a mailing list. but came up with an evenbetter idea, which they called Catapult. Wil presentedan example experiment and showed how Etsy usesCatapult to leverage it. In Catapult, you use web formsto set up the launch, cong the feature, and denemetrics. The GUI outputs the code block that you canthen copy and paste into your conguration le. Afterdeployment, Catapult tracks the experimental results.

    Catapult brings the awareness that Etsy needs forcontinuous deployment. It brings together muchinformation into one place so that people dont haveto hunt for it elsewhere.

    Wil ended his presentation with some suggestions:

    If youre starting out, I would suggest starting simple.Start with what you have and use it until you outgrowit and then build the next iteration, just like we dowith stuff on the site in terms of whats our minimalviable product or how can we do this in the quickestway possible to meet the need and then evolve. Andthen build processes that enable you to ship. A keymantra of development at Etsy is just ship. Just ship.Always be shipping.

    About the speaker

    Wil Stuckey is software engineer at Etsy.

    Presentation Summary by Ben Linders



  • 7/21/2019 EMag Lean Startup

    18/22Page 18Contents

    Lean Startup / Issue 6 - November 2013

    Communicate Business Valueto Your StakeholdersBy Jenni Jepsen

    Ill let you in on a secret: I dont care what letter

    you put in front of DD. I dont care so much about

    how code is written or the ins and outs of software

    development. Its not because I dont realize how

    incredibly important it is, its because what I care

    most about is the value delivered. How can what

    you do save me time, money, and/or frustration? Im

    smart enough to know that without you, the incredibly

    talented member of the development team, my lifewill go into a tailspin. Nothing will work. I realize and

    appreciate that what you develop creates value for me.

    So why is it then that when an IT team wants to

    really understand their stakeholders needs, improve

    perceived results, gain greater visibility from

    the organization, increase the likelihood of more

    funding, or attract talented people to the project,

    they sometimes feel challenged? Because they have

    a tough time communicating the value they aredelivering, or getting their stakeholders to articulate

    the real benets they desire.

    Stakeholders in your organization need to understand

    what it is you will do for them in a language that

    creates meaning for them. And you need to help them

    do that. But how?

    Whats in it for my stakeholders?

    First, let me dene stakeholders. I like ScottAmblers denition: Anyone who is a direct user,

    indirect user, manager of users, senior manager,

    operations staff member, the gold owner who

    funds the project, support (help desk) staff member,

    auditors, your program/portfolio manager, developers

    working on other systems that integrate or interact

    with the one under development, or maintenance

    professionals potentially affected by the development

    and/or deployment of a software project.

    So why dont your stakeholders always understand

    the value you deliver? Because often project leaders,even agile project leaders, talk about their projects

    or processes in terms of features. Its not their fault,

    stakeholders do the same. We need faster processes,

    better user interfaces, more efcient, system-

    supported workows. Yes, but what do these things

    mean for the stakeholder? Whats in it for them? And

    what does it mean for your organization as a whole?

    You can communicate exactly whats in it for your

    stakeholders by communicating in terms of benets,

    not features. Features are what your system orprocess can do. Benets are why people care.

    The most straight-forward denition of each (which

    comes out of the marketing world) are:

    Feature: a characteristic that is special or


    Benet: an advantage that is meaningful for your


    Frederieke Ubels, scrum process coach at Bol.com inthe Netherlands, commented to me that she thinks of

    benets as more universal: Everybody wants to feel

    happy and safe, make money, have happy customers,

  • 7/21/2019 EMag Lean Startup

    19/22Page 19Contents

    Lean Startup / Issue 6 - November 2013

    etc. Features help to achieve benets, but only if and

    when they are used not so universal, more of the

    conditional kind, she says. Features can be used, but

    they can also not be used. It is up to you if you value

    them or not.

    Sell with the benet; support

    with the featureMarketers have been selling us the benets since

    the beginning of time. I dont really want the wheel, I

    want something that is easier to roll or even better,

    something that makes transport easier so I save time

    and energy. I dont want a new car, I want something

    that gets me from A to B quickly so I save time, is safe,

    and looks cool so that I feel good driving it.

    The same goes for projects. I dont want to be able tosearch a certain way in a database. I want to get the

    information I need when I need it, to save time and

    frustration. I dont want to analyze customer needs. I

    want to satisfy customers, so they keep buying from

    us and my company makes more money.

    Saving time. Feeling secure. Experiencing little or no

    frustration. Earning more money. These are the real

    benets. These are the things that create business

    value. It is important that we know how to sell(or, as Id rather say, communicate) the benets to


    Its the benets that connect with our emotions that

    create a desire for something. The relatively new eld

    of neuromarketing explores how these connections

    work. Basically, when we create a tangible connection

    to something, especially something that connects to an

    emotion or one that we can see, touch, hear, smell or

    taste, a memory of it is embedded deep in the brain. Itis in this part of the brain that decisions are made. So,

    if you can nd a way to connect on an emotional level

    with your stakeholder, you are much closer to creating

    understanding, having them on your side when you

    are looking for more resources or support, and working

    to reach your own value-adding goals.

    But communicating the benets is not enough.

    You also need to talk to the logical part of peoples

    brains that want the facts, the data, the researchbehind things. These are your features. They are all

    the capabilities that let you deliver the benet: the

    business value to your stakeholder.

    Start by talking about the value you deliver and

    support your messages with features. As you get

    better at this, you can steal from marketing experts

    who tell stories that t the stakeholders world.

    Create a story that clearly shows you understand

    whats in their heart and mind.

    For example, one such story (slightly exaggerated)

    might be:

    In a time only a few iterations away, our CRM clients

    will be able to turn on their PCs and immediately

    search and nd the customer information they need

    in any form. It could be a shipping address, their

    very rst purchase order, a list of most-purchased

    items. They can cross-reference against other orders,

    including other customers in the same company andwith outside companies, and see trends. They will

    become smarter, more trusted CRM representatives,

    and their customers will be ecstatic. Our CRM clients

    will become rich and fullled and, in turn, so will we.

    Together, we will all live happily ever after.

    Question until you get to the benetWhat if you dont know the benet? Or worse, what

    if your stakeholder does not know the benet? Then,

    you need to ask a lot of questions. If you prefer theFive Whys, use it. If you want to question in a more

    conversational style, try the following:

    So what? questions to understand the beneft

    (assuming your stakeholder knows what the beneft is):

    Whats in it for my stakeholder?

    Whats the purpose of the (feature stakeholder


    What do you (the stakeholder) want to be able to do?

    What advantage does this (feature) bring?

    Questions to help your stakeholder discover/

    understand the real beneft (business value) (assuming

    your stakeholder cannot articulate the beneft):

    Why would I (stakeholder) want or need this?

    What can I (stakeholder) do with it?

    Why is this (feature) better than others?

    Why should (the stakeholder) care about this


    To get at the real benets (business value),

    ask why each feature is included to begin with. Take

    that answer and ask how does this connect with the

  • 7/21/2019 EMag Lean Startup

    20/22Page 20Contents

    Lean Startup / Issue 6 - November 2013

    stakeholders desires? This will help you get to whats

    in it for the stakeholder at an emotional level.

    There can also be situations where you have more

    than one stakeholder, and they may not necessarily

    agree on what the real benet is. For instance, a

    customer-service manager may say having satisedcustomers who make repeat business is the benet.

    His director may say the benet is the revenue earned

    and not the happy customers. In this case, you could

    argue that you need happy customers in order to

    make money. Question until you understand what the

    main benet is. And if you need to, create a hierarchy

    of benets that can then be supported with specic


    User-story format as a starting pointComing from the non-IT world, I know nothing, really,

    about software development. But having worked

    for more than 20 years in marketing and leadership

    and change communications, I do know the value of

    communicating in terms of benets. Start with the

    benet message, I always advise my clients. You

    need to get people to care about what it is you are

    doing for them!

    Clever minds like Chris Matts and Andy Pols, DanNorth, Liz Keogh, and others talk about behavior-

    driven development and stakeholder stories (rather

    than user stories) in order to understand the business

    value a stakeholder is looking for. The common user-

    story format is a good starting point. Teams are trying

    to get to the benet.

    As a (role, persona),

    I want (goal, what will the feature do, why is it useful),

    so that (benet/business value).

    From a pure communications perspective, one would

    quickly suggest turning the common user-story

    format upside down (and that is what I now know

    Chris Matts suggested in 2008). Heres my version:

    We will (benet/business value)

    for our (role, persona),

    because we have (what will the feature do, why is it


    Or simply skip the I want part of the common user-

    story format to focus solely on the end user and the

    benet. This puts the least constraints on the team,

    since no features are even mentioned.

    Here is a simplied example that some Siri developers

    at Apple could have worked with:

    As an end-user consumer,

    I want to be able to make changes to my calendar and

    search without having to type on my iPhone, because it

    saves me time and hassle. (Its also safer if I happen to bedriving.)

    A stickier way of communicating this so that the

    benet comes rst is:

    We will save time and hassle, and increase safety

    for our end-user consumers,

    because we have an intelligent personal assistant that

    can make changes to calendars and search using a natural

    language user interface.

    Im not proposing that using the benet-rst is

    necessarily the right way when it comes to software

    development. What I am saying is that starting with

    the benet message is the way to effectively get

    to and communicate the business value.

    Making the benet message stickWhen Im working with teams who are having

    difculties getting their stakeholders to understand

    the value of their projects, it is usually because theteam does not know how to communicate in terms

    of the value they are delivering. Understanding

    what the value is and then starting with the benet

    message are rst steps. But how, then, do you make

    the message top of mind for your stakeholder, so that

    your stakeholder can also communicate the business

    value of your project to others inside and outside

    of the organization? You do that by increasing the

    stickiness of your message.

    After working as a journalist and then as an executive-

    communications coach, Ive seen the effectiveness

    of using simple, easy-to-understand messages that

    convey signicance and motivate to action. Chip

    Heath and Dan Heath in Made to Stick outline

    succinctly what I have been teaching for years.

    Here are their Six Elements of Stickiness to make

    messages memorable:

    1. Simple whats the most important thing toremember?

    2. Unexpected how can we grab the stakeholders


  • 7/21/2019 EMag Lean Startup

    21/22Page 21Contents

    Lean Startup / Issue 6 - November 2013

    3. Concrete what is the context that makes the

    benet relevant?

    4. Credible why should stakeholders believe this?

    5. Care whats in it for me the stakeholder?

    6. Act what should I do now?

    Incorporate these elements into your benetmessage to make a real imprint in your stakeholders

    mind. Even the best messages do not have all of the

    elements, but they usually have three or four.

    I worked with an IT team responsible for developing a

    patient-tracking system for a large group of hospitals.

    They were not getting the support they needed from

    their stakeholders, and they were not communicating

    the value they were delivering. After getting to the

    benet and thinking about the value they delivered in

    a sticky way, the team came up with the following:Our system saves lives. Doctors and nurses anywhere in

    the country have quick access to patient records. With

    a single sign-on, they can get an immediate overview of

    each patients conditions and medications. They can feel

    secure in knowing they are giving their patients the best

    medical care possible.

    This message contains the following elements:

    SIMPLE, CONCRETE, UNEXPECTED (Our system saves

    lives.),CARE (They can feel secure in knowing they are giving

    their patients the best medical care possible.)

    ACT (With a single sign-on)

    The advantage is that the benet message is powerful

    and easy for the team and stakeholders to remember

    and articulate. It serves as the basis for every

    communication that is made about the value the team

    is delivering with this system.

    Enhanced communications builds trustSo what is your benet in improving your

    communications about the benets of your project

    with your stakeholder? The biggest benet is

    building trust. In order to gure out the value for

    the stakeholder, you need to have (or at least start

    building) a relationship with them. This happens

    through the benet-communications process. And

    when you talk about the benets of your project in a

    language that resonates with stakeholders, it helpsthem to trust you especially when you deliver that

    value. It becomes a self-perpetuating cycle: the more

    you talk about the benets (or business value) of your

    project and the more you deliver those benets, the

    stronger your relationships with stakeholders become

    and the more value you are able to create.

    Practical tools to increaseunderstandingThe next time you are working with your stakeholders

    to gather requirements, start by talking about the

    benet or business value. Make sure the benets are

    real. Making a visual representation is an excellent

    and very agile way to create a common understanding

    of these benets. (Effect-mapping, other types of

    mindmaps, and vision boxes can help the process.)

    Heres an example of a vision box for a large company

    in Denmark. It has the projects brand and logo on one

    side, another has benets, and the sides you cant seelist the features.

    Heres some nal advice. Increase communication

    effectiveness between teams and stakeholders by:

    Understanding the real benet

    Supporting with features

    Asking questions Creating your benet-rst user story

    Proting from making your benet messages stick

    Focusing on building trust through the process

  • 7/21/2019 EMag Lean Startup


    Lean Startup / Issue 6 - November 2013

    See for yourself the difference communicating

    business value will make in creating better

    understanding, achieving goals together, and working

    in relationships of trust.

    About the author

    Jenni Jepsen has more than 20 years experience

    helping individuals, teams, and organizations use

    strategic communications to align with business

    goals, create meaning for stakeholders, and build

    trust through the process. This way of communicating

    opens the way to better understanding, increased

    collaboration, and quicker results effectively leading

    teams to success. Jenni speaks, writes, and consults

    on how organizations can increase their business

    value enterprise-wide.

    READ THIS ARTICLE ONLINE ON InfoQhttp://www.infoq.com/articles/communicate-business-value-