EMag Lean Startup

Facilitating the spread of knowledge and innovation in enterprise software development
LEAN
by
STARTUP
eMag Issue 6 - November 2013
Sell
Before
You
Build
TDD 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 finding effective MVPs.
Page 3
Minimum Viable
Products for
Enterprises
Building Scalable
Products that
Customers Love
Enterprise software startups use a

minimum viable product (MVP) to
learn about customers with limited
effort and money.
Per Jonsson discusses Lean

Startup in the context of real
world examples, and helpful tools
for startups.
Page 8
Contents
Page 10
Interview with
Brian Murray
from Yammer
about Lean Startup
and using Minimum
Viable Products
Page 12
Contents
Sell Before You Build
Page 3
TDD 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 finding effective MVPs.
Minimum Viable
Products for Enterprises
Page 8
Enterprise 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 Products

that Customers Love
Page 10
Per 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 Murray

from Yammer about Lean Startup
and using Minimum Viable Products Page 12
Brian 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 a
Continuously Deployed EnvironmentPage 16
Wil 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 Value

to Your Stakeholders
Page 18
Learn why and how to communicate benefits rather than

featuresand what it will mean for you, your team and your organization.
Contents
Page 2
Lean Startup / Issue 6 - November 2013
Sell Before You Build

By Naresh Jain
Over the last four years of building my own startups
and involvement with various other startups, the most
important lesson Ive learned is Sell your product/idea
before you build it. Seriously!
During this journey, Ive met many successful founders
and their most important advice has always been Do
you have paying customers? If not, first get them and
then think of building a product that addresses their
real needs. It sounds to me, having been a test-driven
development veteran, like Do you have failing tests
before you write/modify any code?
At Kickstarter, an impressive 44% of projects have met
their funding goals before theyve started building a
product. Applying this validation-driven approach to
new product/service development certainly sounds
fascinating and desirable. I would love to momentarily
pause time while people line up on my doorstep
waiting to pay me hard cash for a product that doesnt
even exist. Its worth a shot, right?
At Edventure Labs, when we started validating our
idea of teaching five-year-old kids scientifically proven
mental arithmetic skills, which lets them calculate
faster than a calculator, we realized our potential
customers (parents of five-year-olds) only vaguely
understood the problem we were trying to solve. To
them, it was about number crunching, which is an
obsolete skill replaced by electronic gadgets. To make
matters worse, they believed kids had to be born
a genius to calculate faster than a calculator. They
did not know if their kids were capable of or even
interested in acquiring this skill. We simply could not
get any real feedback from talking to parents. If we
tried to sell them our product (an educational game
to teach mental arithmetic), they would immediately
Contents
change the topic as if wed uttered some taboo.

We had to figure out how to have a meaningful
conversation with our potential customers. We could
hire a world-class team, build the product, hire some
kids to go through our educational program, and then
show real data to the parents to prove the importance/
feasibility of our product. However, existing teaching
methods take a minimum of 10 minutes of practice
every 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 teaching
and evaluation techniques, etc. This would easily take
another six months. So we were looking at a minimum
24-month horizon, assuming we knew exactly what
needed to be done, before we could actually have
this conversation with parents and acquire paying
customers.
If I were a typical agile product owner, I would say, Its
a very high-risk project. Its best to skip it. However
as startup founders, we were convinced that this
could change the world and hence the risk was totally
worth it. In fact, we told ourselves that because its
so hard, no one else had yet solved this problem or
built a successful product. So lets go full swing, hire a
team, do a collaborative product-discovery workshop
with them, come up with a release roadmap, and start
sprinting. That was absolutely the best and fastest way
to burn all our funds and destroy our dreams.
Instead, we ran a series of experiments to answer open
questions and through this process completely refined
our strategy and our product. Over the last two years,
our vision has remained the same, but weve done nine
significant pivots and finally we feel weve nailed it.
Page 3

First, we had to figure out an effective teaching
technique for five-year-olds. We wanted real data as
a baseline to validate the retention power of different
teaching techniques. We picked the introduction
to abacus (one of the tools we use to teach mental
arithmetic) 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 a
33-second animation that introduced the abacus.
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.
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 and
require a lengthy turnaround even for small changes.
It was clearly a bad strategy.
Another major question we had to figure 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. How
many free app users would pay for the paid app? We
figured 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 find
distributors/partners? We launched Abacus Rush in
Google Play as a free app called World of Numbers.
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 kids
could. 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
Contents
Page 4

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 fix 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 figure out our product
strategy, but let me step back and quickly recap what
we learned and explore how you can use some of
these techniques.
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 scientific framework
for conducting many safe-fail experiments. In leanstartup 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 fulfil 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 of
experiments 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.
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 figure out how to package and
pitch your product to really appeal to your target
customers. For many years, startups primarily
focused on building their dream products. They
probably spent time creating a business model, but
mostly ignored customer development (acquisition
Contents
Business Facing
Are we building the right product?
Are we building the product right?
Technology/Implementation Facing
Page 5

Agile methods are really good at addressing the
second question. To some extent, they also help you
answer the first question; however, there is certainly
a delay in getting that feedback. Typically you get that
feedback at the end of your first iteration/sprint and
in some cases only during your first release.
agile methods seems like a bit of shooting in the dark.

Its a gamble!
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 and
dirty for experimentation with real customers is
something many agile folks look down upon.
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 benefits they expected from agile methods.
If you think about it, agile methods flourish 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, they
dont really know or recognize their pain points,
especially in end-consumer facing products, and
relying completely on your product owner and using
Contents
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:
Jeff was one of the pioneers who spotted this

gap in agile methods and tried to fill it with userstory mapping and, later, product discovery. The
collaborative nature of these product-discovery
sessions 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 scientific approach to running a series
of safe-fail experiments. Lean startup also focused
heavily on customer development and businessmodel validation, which agile methods completely
missed. It was mostly left to the product owner to
solve these complex puzzles.
This is just the beginning of a new era of scientific
Page 6

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 just
like a startup. They are running parallel cheap, safefail experiments on multiple initiatives and finally
choosing the most promising initiative instead of
picking one initiative right at the beginning based on
personal preference or gut feeling.
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 figure out the
secret sauce for blending gamification and social
learning using the latest gadgets. In 2004, Naresh
founded the Agile Software Community of India, a
registered non-profit society to evangelize agile, lean,
and other lightweight methods in India.
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 that
enterprises 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 Author

Naresh Jain - Tech-startup founder and agile/
lean evangelist
Naresh Jain is an internationally recognized
technology and process expert. As an independent
Contents
Page 7
Read this article online ON InfoQ

http://www.infoq.com/articles/sell-before-you-build
Minimum Viable Products

for Enterprises
By Ben Linders
The purpose of aminimum viable product (MVP),
as defined byEric Ries inlean startup,is to expend
limited effort and money to learn about customers
. In the blog postThe 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 startupintends to make and organization more
efficient by quickly finding out ifthere is a need for a
product thatit wants to develop.But organizations
sometimesfind itdifficultto define a minimum viable
product:
We all understand what Product means, and
Minimummakessense: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? (thatll
never happen, Im a visionary dont you know)
When we bring in revenue?
When we make profit?
Contents
In the Forbes articleThe Times Are Changin:

The Evolution of Enterprise Software, the
director of enterprise strategy at Yammer,
Brian Murray,describes what is changingin the
development of enterprise software with lean startup,
and why these changes are necessary:
A rampant inefficiency 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 efficiently test their hypotheses
and ultimately create a product that slowly and
continuously evolves into what it should be, not what
peoplethinkit should be.
In the blog postMinimum Viable Product vs
Minimum Delightful Product, Adam Berrey gives his
viewon how a enterprise minimum viable product
looks:
...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 Rodriguezexplains in his blog postThe
Enterprise Minimum Viable Product: Focus on
Viable Instead of Minimumhow enterprise software
development is different from consumer product
development when it comes to minimum viable
Page 8

products. In the consumer market,the user of the
softwareis also the buyer. Thisis rarely the casein the
enterprise world, which challenges getting product
feedback:
...The people trying the MVP are rarely the ones
making the ultimate purchase decision.... Enterprise
software startups need to be able to carefully
evaluate the feedback received from an MVP, filtering
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 softwareis 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 postLessons from Agile The
Minimum Viable Product describes why they used
the minimum viable product for a complex enterprise
initiative:
Sam describes a five-step process to identify and

define an enterpriseminimum viable product.
The stepsare 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) atwww.benlinders.com and on his twitter
page@BenLinders.
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 explainshow he seesa minimum viable product,
and how you can usethat 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 next
iterations that would deliver maximum business
benefit and customer delight.
Contents
Page 9
READ THIS ARTICLE ONLINE ON InfoQ

http://www.infoq.com/news/2013/01/enterprise-MVP
Building Scalable Products

that Customers Love
By 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, was
that 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. But
he also made clear they were running a web startup,
where nine out of ten fail. Why do they fail in the first
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
Contents
is that as soon as youve written it, its by definition

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 what
we do. We actually said no to many startups because
the first 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 opinion
in 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
Page 10

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 need
to test it. To test it, you need to have a prototype of
some sort.
The center of the validation process is finding 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 your
discovery phase then.
Per ended his talk with some suggested readings
about lean startup:
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 if
you dont need it now, why build it now? It creates
complexity in the product before its necessary.
About the speaker:
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.
Per Jonsson is a Swedish entrepreneur and engineer

passionate about creating technology that simplifies
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.
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?
The Four Steps to the Epiphany by Steve Blank

The Lean Startup by Eric Ries
Lean Entrepreneur by Brant Cooper andPatrick
Vlaskovits
Presentation Summary by Ben Linders.

Watch the full presentation online on InfoQ
http://www.infoq.com/presentations/Startups
Per explained that this is where you often have to go

back 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 these
things and start the company, you burn a lot of money
and thats when VCs get really angry with you.
Contents
Page 11
Interview with Brian Murray

from Yammer about Lean Startup
and Minimum Viable Products
By Ben Linders
Enterprises are finding ways to adopt thelean
startupapproach 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 itemMinimum Viable Products for
Enterprisesgives some examples of how enterprises
can uselean startupwith 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 briefly introduce

yourself 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.
Contents
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 and
mitigating 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 release
products 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
Page 12

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-asa-service model. However, with the introduction of
cloud architecture, we can make changes quickly to
our products and ultimately avoid making too many
assumptions, and thats key here. In a traditional
enterprise-development model, you would have twoor-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.
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?
With Yammer we make small assumptions. We have

hypotheses and we are able to test them quickly
over 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.
An interesting example of this is a new feature that

is called Universal Publisher. Universal Publisher
represents a really significant 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
significant 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 architecture
refinements, 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: Yammer is applying the lean-startup

approach. Why did you choose this, and how
did 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 efficient, and allowed
the 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.
Contents
Brian:We almost always try to employ an MVP model

in our feature set. This isnt to say that we release halfbaked features, but that we have hypotheses as to what
our 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.
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?
Page 13

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 specific and predictable go live date in
traditional 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 advanced
communication so that our champions and our
administrative teams on the customer side are fully
aware of the change and implications. We also want
to confirm 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 on
these 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
Contents
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 rapiditeration 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 into
an 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 benefits
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 benefit 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, profiles, 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
Page 14

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 doing
that, we are able to again optimize more efficiently
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 significant
advantage in being able to improve these different
services individually. Lean helped us realize that
decoupling 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 evolving
demand. 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 read
literature 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
Contents
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 influenced 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 Interviewee

Brian Murrayis 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.
Page 15

http://www.infoq.com/articles/brian-murray-lean-startup
Managing Experimentation in a
Continuously Deployed Environment
By 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 classifies 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 config system at Etsy works with branching in
code and not with feature branches in the version
management, Wil explained. This helps to fine-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
Contents
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 refinements to the code that fixes bugs or could
mean a configuration change that Etsy is opening up
for a new set of people.
One of the first 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 an
audience 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 traffic 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 refinement.
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 collects
structured metadata about launches in a central
repository where people can find whats upcoming,
whats current, and what is past:
Page 16

Presentation Summary by Ben Linders
Watch the full presentation online on InfoQ
http://www.infoq.com/presentations/etsy-deploy
Etsy used Launch Calendar to send a daily email

update to a mailing list. but came up with an even
better idea, which they called Catapult. Wil presented
an example experiment and showed how Etsy uses
Catapult to leverage it. In Catapult, you use web forms
to set up the launch, config the feature, and define
metrics. The GUI outputs the code block that you can
then copy and paste into your configuration file. After
deployment, Catapult tracks the experimental results.
Catapult brings the awareness that Etsy needs for

continuous deployment. It brings together much
information into one place so that people dont have
to 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 outgrow
it and then build the next iteration, just like we do
with stuff on the site in terms of whats our minimal
viable product or how can we do this in the quickest
way possible to meet the need and then evolve. And
then build processes that enable you to ship. A key
mantra of development at Etsy is just ship. Just ship.
Always be shipping.
About the speaker

Wil Stuckey is software engineer at Etsy.
Contents
Page 17
Communicate Business Value

to Your Stakeholders
By 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 life
will 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 are
delivering, or getting their stakeholders to articulate
the real benefits 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 define stakeholders. I like Scott
Amblers definition: Anyone who is a direct user,
indirect user, manager of users, senior manager,
operations staff member, the gold owner who
Contents
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 efficient, systemsupported workflows. 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 benefits,
not features. Features are what your system or
process can do. Benefits are why people care.
The most straight-forward definition of each (which
comes out of the marketing world) are:
Feature:a characteristic that is special or
important
Benefit:an advantage that is meaningful for your
stakeholder
Frederieke Ubels, scrum process coach at Bol.com in
the Netherlands, commented to me that she thinks of
benefits as more universal: Everybody wants to feel
happy and safe, make money, have happy customers,
Page 18

etc. Features help to achieve benefits, 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 alsonotbe used. It is up to you if you value
them or not.
Sell with the benefit; support

with the feature
Marketers have been selling us the benefits 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 to
search 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
benefits. These are the things that create business
value. It is important that we know how to sell
(or, as Id rather say, communicate) the benefits to
stakeholders.
Its the benefits that connect with our emotions that
create a desire for something. The relatively new field
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. It
is in this part of the brain that decisions are made. So,
if you can find 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 benefits is not enough.
You also need to talk to the logical part of peoples
brains that want the facts, the data, the research
behind things. These are your features. They are all
the capabilities that let you deliver the benefit: the
business value to your stakeholder.
Contents
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 fit 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 find the customer information they need
in any form. It could be a shipping address, their
very first purchase order, a list of most-purchased
items. They can cross-reference against other orders,
including other customers in the same company and
with 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 fulfilled and, in turn, so will we.
Together, we will all live happily ever after.
Question until you get to the benefit

What if you dont know the benefit? Or worse, what
if your stakeholder does not know the benefit? Then,
you need to ask a lot of questions. If you prefer the
Five Whys, use it. If you want to question in a more
conversational style, try the following:
So what? questions to understand the benefit
(assuming your stakeholder knows what the benefit 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 benefit (business value)(assuming
your stakeholder cannot articulate the benefit):
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 benefits (business value),
askwhyeach feature is included to begin with. Take
that answer and askhowdoes this connect with the
Page 19

stakeholders desires? This will help you get to whats
in it for the stakeholderat 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 benefit is. For instance, a
customer-service manager may say having satisfied
customers who make repeat business is the benefit.
His director may say the benefit 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 benefit is. And if you need to, create a hierarchy
of benefits that can then be supported with specific
features.
User-story format as a starting point

Coming 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 benefits. Start with the
benefit 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 Mattsand Andy Pols, Dan
North, Liz Keogh,and others talk about behaviordriven development and stakeholder stories (rather
than user stories) in order to understand the business
value a stakeholder is looking for. The common userstory format is a good starting point. Teams are trying
to get to the benefit.
As a (role, persona),
I want (goal, what will the feature do, why is it useful),
so that (benefit/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 (benefit/business value)
for our (role, persona),
because we have (what will the feature do, why is it
useful).
Or simply skip theI wantpart of the common userstory format to focus solely on the end user and the
benefit. This puts the least constraints on the team,
Contents
since no features are even mentioned.

Here is a simplified 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 be
driving.)
A stickier way of communicating this so that the
benefit comes first 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 benefit-first is
necessarily the right way when it comes to software
development. What I am saying is that starting with
the benefit message is the way to effectivelyget
toandcommunicatethe business value.
Making the benefit message stick

When Im working with teams who are having
difficulties getting their stakeholders to understand
the value of their projects, it is usually because the
team does not know how to communicate in terms
of the value they are delivering. Understanding
what the value is and then starting with the benefit
message are first 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 executivecommunications coach, Ive seen the effectiveness
of using simple, easy-to-understand messages that
convey significance and motivate to action. Chip
Heath and Dan Heath inMade 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 to
remember?
2. Unexpected how can we grab the stakeholders
attention?
Page 20

3. Concrete what is the context that makes the
benefit 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 benefit
message 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
benefit 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.
project and the more you deliver those benefits, the

stronger your relationships with stakeholders become
and the more value you are able to create.
Practical tools to increase

understanding
The next time you are working with your stakeholders
to gather requirements, start by talking about the
benefit or business value. Make sure the benefits are
real. Making a visual representation is an excellent
and very agile way to create a common understanding
of these benefits. (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 benefits, and the sides you cant see
list the features.
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 benefit 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 trust

So what is your benefit in improving your
communications about the benefits of your project
with your stakeholder? The biggest benefit is
building trust. In order to figure out the value for
the stakeholder, you need to have (or at least start
building) a relationship with them. This happens
through the benefit-communications process. And
when you talk about the benefits of your project in a
language that resonates with stakeholders, it helps
them to trust you especially when you deliver that
value. It becomes a self-perpetuating cycle: the more
you talk about the benefits (or business value) of your
Contents
Heres some final advice. Increase communication

effectiveness between teams and stakeholders by:

Page 21
Understanding the real benefit

Supporting with features
Asking questions
Creating your benefit-first user story
Profiting from making your benefit messages stick
Focusing on building trust through the process

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

JenniJepsenhas 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.
http://www.infoq.com/articles/communicate-business-valuestakeholders
Contents
Page 22

EMag Lean Startup

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

EMag Lean Startup

Încărcat de

Drepturi de autor:

Formate disponibile

Facilitating the spread of knowledge and innovation in enterprise software development

TDD was a revolutionary idea in the late 90s.

Enterprise software startups use a

Per Jonsson discusses Lean

TDD was a revolutionary idea in the late 90s. Entrepreneurs practice a

Enterprise software startups use a minimum viable product (MVP) to learn

Building Scalable Products

Interview with Brian Murray

Communicate Business Value

Learn why and how to communicate benefits rather than

Lean Startup / Issue 6 - November 2013

Sell Before You Build

change the topic as if wed uttered some taboo.

Lean Startup / Issue 6 - November 2013

apply the logic to other numbers. Most kids could do

We got a bunch of kids to watch this animation

Another major question we had to figure out was

Inspired by mobile games, we came up with a

Lean Startup / Issue 6 - November 2013

will not work! The 120K downloads certainly helped

and retention). Figuring out a sustainable business

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

As startup founders, we might have a knack of

Are we building the product right?

Lean Startup / Issue 6 - November 2013

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

Getting this feedback in a few weeks or at most three

Quadrant 1 seems like a natural habitat for agile

If you think about it, agile methods flourish when

I remember sitting at a bar in downtown Chicago in

Jeff was one of the pioneers who spotted this

Lean Startup / Issue 6 - November 2013

consultant, Naresh worked with many Fortune

Last time I visited a large energy company, I heard

About the Author

Read this article online ON InfoQ

Lean Startup / Issue 6 - November 2013

Minimum Viable Products

In the Forbes articleThe Times Are Changin:

Lean Startup / Issue 6 - November 2013

Sam describes a five-step process to identify and

About the author

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

READ THIS ARTICLE ONLINE ON InfoQ

Lean Startup / Issue 6 - November 2013

Building Scalable Products

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

Lean Startup / Issue 6 - November 2013

The center of the validation process is finding your

The lean startup is all about minimizing waste, said

About the speaker:

At the beginning, look for your minimum viable

Per Jonsson is a Swedish entrepreneur and engineer

The discovery phase is all about the problem and

The Four Steps to the Epiphany by Steve Blank

Presentation Summary by Ben Linders.

Per explained that this is where you often have to go

Lean Startup / Issue 6 - November 2013

Interview with Brian Murray

InfoQ: Brian, can you briefly introduce

InfoQ: Would you describe your role

InfoQ: How big is Yammer right now?

InfoQ: In an article last year in Forbes (mentioned

Lean Startup / Issue 6 - November 2013