EMag Lean Startup

7/21/2019 EMag Lean Startup

1/22Contents

LEANSTARTUPeMag Issue 6 - November 2013

by

Minimum Viable

Products for

Enterprises

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

SellBefore

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

FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN ENTERPRISE SOFTWARE DEVELOPMENT
http://www.infoq.com/


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

stakeholders?

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

change.

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.

Contents


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


4/22Page 4Contents


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.


5/22Page 5Contents


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?


6/22Page 6Contents


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/22Page 7Contents


experimentation in the product-development

space. Im pretty excited to see how lean-startup

principles and thinking are already penetrating large

enterprises.

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
http://www.infoq.com/articles/sell-before-you-buildhttp://www.infoq.com/articles/sell-before-you-buildhttp://www.infoq.com/articles/sell-before-you-build


8/22Page 8Contents


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

product:

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


9/22Page 9Contents


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

feedback:

...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

features:

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.

READ THIS ARTICLE ONLINE ON INFOQ

http://www.infoq.com/news/2013/01/enterprise-MVP
http://www.infoq.com/news/2013/01/enterprise-MVPhttp://www.infoq.com/news/2013/01/enterprise-MVPhttp://www.infoq.com/news/2013/01/enterprise-MVP


10/22Page 10Contents


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

canvas.

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




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

Vlaskovits

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.

WATCH THE FULL PRESENTATION ONLINE ON INFOQ

http://www.infoq.com/presentations/Startups
http://www.infoq.com/presentations/Startupshttp://www.infoq.com/presentations/Startupshttp://www.infoq.com/presentations/Startups




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,

globally.

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




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?




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




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

experience.

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
http://www.infoq.com/articles/brian-murray-lean-startuphttp://www.infoq.com/articles/brian-murray-lean-startuphttp://www.infoq.com/articles/brian-murray-lean-startup




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:




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

WATCH THE FULL PRESENTATION ONLINE ON INFOQ

http://www.infoq.com/presentations/etsy-deploy
http://www.infoq.com/presentations/etsy-deployhttp://www.infoq.com/presentations/etsy-deployhttp://www.infoq.com/presentations/etsy-deploy




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

important

Benet: an advantage that is meaningful for your

stakeholder

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,




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

stakeholders.

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

wants)?

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

(feature)?

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




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

features.

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

useful).

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

attention?




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


22/22


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-

stakeholders
http://www.infoq.com/articles/communicate-business-value-stakeholdershttp://www.infoq.com/articles/communicate-business-value-stakeholdershttp://www.infoq.com/articles/communicate-business-value-stakeholdershttp://www.infoq.com/articles/communicate-business-value-stakeholders

EMag Lean Startup

Documents

Transcript of EMag Lean Startup