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 90’s. 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 MVP’s.

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 90’s. 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 MVP’s.

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 features—and 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 I’ve learned is “Sell your product/idea before you build it.” Seriously! During this journey, I’ve 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 they’ve 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 doesn’t even exist. It’s 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 we’d 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, “It’s a very high-risk project. It’s 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 it’s so hard, no one else had yet solved this problem or built a successful product. So let’s 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 we’ve done nine significant pivots and finally we feel we’ve nailed it.

Page 3

Lean Startup / Issue 6 - November 2013 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

Lean Startup / Issue 6 - November 2013 To our surprise, we crossed 120K downloads in a week’s time. All we’d 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. It’s 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 don’t 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, let’s 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

Lean Startup / Issue 6 - November 2013 Agile methods are really good at addressing the second question. To some extent, they also help you answer the 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. It’s 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 don’t 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 don’t 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

Lean Startup / Issue 6 - November 2013 experimentation in the product-development space. I’m 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 “Let’s 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

Lean Startup / Issue 6 - November 2013

Minimum Viable Products for Enterprises By Ben Linders The purpose of a minimum viable product (MVP), as defined 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 efficient by quickly finding out if there is a need for a product that it wants to develop. But organizations sometimes find it difficult to define 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? (that’ll never happen, I’m a visionary don’t you know) • When we bring in revenue? • When we make profit?

Contents

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 inefficiency in traditional enterprise technology development is the attempt to build the perfect product before it’s 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 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 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. You’re off and running. Jesus Rodriguez explains in his blog post The Enterprise Minimum Viable Product: Focus on Viable Instead of Minimum how enterprise software development is different from consumer product development when it comes to minimum viable

Page 8

Lean Startup / Issue 6 - November 2013 products. In the consumer market, the user of the software is also the buyer. This is rarely the case in the enterprise world, which challenges getting product 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 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 Palani’s blog post Lessons 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 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 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 stakeholder’s 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 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

Lean Startup / Issue 6 - November 2013

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 team’s 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 Sweden’s best programmers, and they were two business engineers thinking they’re 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 didn’t 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 it’s 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: Don’t 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 you’ve written it, it’s by definition obsolete because the market is always changing. So you’re sitting there with this huge document in which you’ve invested a lot of time and energy but it doesn’t 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. I’ve 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.” Don’t make assumptions. This is extremely hard when you’re a founder with, as most founders, lots of ego. Entrepreneurs, in general, VCs, board members…everybody 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 it’s 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

Lean Startup / Issue 6 - November 2013 agile development. You have iterations or you iterate on something. The difference here is that you integrate the customer-feedback loop into the validation. Every time you have an iteration, you start with an hypothesis, for example, “I think if we write this blog post, it will get us at least 100 subscribers.” And then when you have your hypothesis, you 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. It’s focusing more on early-stage companies, basically. And in the beginning, you want to focus on problem solution because that’s 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 don’t need, doing the wrong things, or building a product that is too big. The other is inventory: you build something immediately because you’re going to need it later and your team is passionate about building it. But if you don’t need it now, why build it now? It creates complexity in the product before it’s 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 don’t 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 and Patrick 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 we’re looking at is too small and it’s not growing. So we’re 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, it’s about the fact that you can’t 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 that’s when VCs get really angry with you.

Contents

Page 11

Lean Startup / Issue 6 - November 2013

Interview with Brian Murray from Yammer about Lean Startup and Minimum Viable Products By Ben Linders Enterprises are finding 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, Yammer’s 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:  I’ve 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 I’ve 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

Lean Startup / Issue 6 - November 2013 adopted by all technology vendors for a number of reasons. The primary reason is that it’s available now. Historically speaking,  when the Internet was not as powerful, when applications were purely on-premise models, it just wasn’t 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 that’s 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 what’s 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. It’s what allowed us to compete when we were just starting up and it’s 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 isn’t 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, you’re 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 it’s either private or public? We have some ideas about what might work but we can’t say with certainty that one implementation of that idea is better than another, so that’s 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

Lean Startup / Issue 6 - November 2013 Brian: Again, my past experience before joining Yammer was rolling out traditional enterprise technologies, large ERP systems, CRM systems, and these projects would take a year if not more. Part of that was the change management in the communication and the training involved in rolling out the new technology to make sure it was adopted. You have a 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! That’s 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 we’ve 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 it’s 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. It’s about breaking down big ideas into smaller, more consumable chunks and introducing those in a way that’s 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 there’s 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 that’s 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 what’s working and what’s not working. One major benefit is that the feedback loop helps our product managers make better and better hypotheses over time because they see what’s 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 didn’t, 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, Yammer’s is distributed. This allows us to improve any one of these services independently, so we can enhance

Page 14

Lean Startup / Issue 6 - November 2013 one service without worrying too much about what the trickle-down effect will be on everything else. We’ve learned that by decoupling the services that power Yammer, we are able to innovate faster. In fact, we’ve 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 you’ll 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. It’s 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. We’ve just employed those practices over time; it’s always been in the back of our minds. We don’t consider it an option, more of a core

Contents

principle that we all need to adhere to. It’s been really great to have a founding team that’s so committed to this philosophy and it’s 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 you’re 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 feature’s 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. That’s 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 Murray is director of enterprise strategy at Yammer, where he helps shape the company’s 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

Read this article online ON InfoQ http://www.infoq.com/articles/brian-murray-lean-startup

Lean Startup / Issue 6 - November 2013

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 doesn’t bring down the site. Communication is a catch-all bucket for things that aren’t 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 it’s 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 what’s upcoming, what’s current, and what is past:

Page 16

Lean Startup / Issue 6 - November 2013 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 don’t have to hunt for it elsewhere. Wil ended his presentation with some suggestions: If you’re 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 what’s 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

Lean Startup / Issue 6 - November 2013

Communicate Business Value to Your Stakeholders By Jenni Jepsen I’ll let you in on a secret: I don’t care what letter you put in front of ”DD”. I don’t care so much about how code is written or the ins and outs of software development. It’s not because I don’t realize how incredibly important it is, it’s because what I care most about is the value delivered. How can what you do save me time, money, and/or frustration? I’m 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?

What’s in it for my stakeholders? First, let me define ”stakeholders”. I like Scott Ambler’s 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 don’t 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. It’s 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? What’s in it for them? And what does it mean for your organization as a whole? You can communicate exactly what’s 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

Lean Startup / Issue 6 - November 2013 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 also not be 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 don’t 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 don’t 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 don’t 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 don’t 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 I’d rather say, “communicate”) the benefits to stakeholders. It’s 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 people’s 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 stakeholder’s world. Create a story that clearly shows you understand what’s 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 don’t 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): • What’s in it for my stakeholder? • What’s 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), ask why each feature is included to begin with. Take that answer and ask how does this connect with the

Page 19

Lean Startup / Issue 6 - November 2013 stakeholder’s desires? This will help you get to “what’s 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 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 Matts and 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). Here’s 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 the “I want” part 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. (It’s 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. I’m 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 effectively get to and communicate the business value.

Making the benefit message stick When I’m 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, I’ve seen the effectiveness of using simple, easy-to-understand messages that convey significance 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 – what’s the most important thing to remember? 2. Unexpected – how can we grab the stakeholder’s attention?

Page 20

Lean Startup / Issue 6 - November 2013 3. Concrete – what is the context that makes the benefit relevant? 4. Credible – why should stakeholders believe this? 5. Care – what’s 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 stakeholder’s 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 patient’s 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.) Here’s an example of a vision box for a large company in Denmark. It has the project’s brand and logo on one side, another has benefits, and the sides you can’t 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

Here’s 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

Lean Startup / Issue 6 - November 2013 See for yourself the difference communicating business value will make in creating better understanding, achieving goals together, and working in relationships of trust.

About the author Jenni Jepsen has more than 20 years experience helping individuals, teams, and organizations use strategic communications to align with business goals, create meaning for stakeholders, and build trust through the process. This way of communicating opens the way to better understanding, increased collaboration, and quicker results – effectively leading teams to success. Jenni speaks, writes, and consults on how organizations can increase their business value enterprise-wide. Read this article online ON InfoQ http://www.infoq.com/articles/communicate-business-valuestakeholders

Contents

Page 22