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 about how enterprises can use lean startup to learn about customers with limited effort and money. One of the companies mentioned in this InfoQ news was Yammer, and InfoQ talked with Brian Murray 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: I'm talking with Brian Murray, director of enterprise strategy at Yammer. Brian, can you briefly introduce yourself to the InfoQ readers?
Brian: Sure, 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 spent about half my time at Yammer on the customer engagement side, helping companies make sense of this new way of communicating and the other half on the product team helping shape the direction of our product and evangelize and explain this new way of creating our product and iterating on it rapidly.
InfoQ: Being on a product team, would you describe your role as also being 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 also the pure creative designers, so they are the ones creating the look and feel of Yammer. The other category is pure product management, so this 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 which 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: Just to have an indication, how big is Yammer right now?
Brian: Yammer has about 450 employees now, globally.
InfoQ: In an article last year in Forbes that was 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 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 where deployed purely on-premise models, it just wasn’t possible to have a software as a 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 two or three year release cycles and you would have to make a lot of assumptions as to what your users were going to expect from your technology by the time it was released to market. With Yammer we make small assumptions, we have hypotheses and we are able to test them 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.
InfoQ: I have understood that 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 whole-heartedly 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.
InfoQ: Minimal Viable Products (MVP) are used to deliver light versions of new features of Yammer. Can you give some examples of how this has been used?
Brian: We almost always try to employ an MVP model in our feature set. This isn’t to say that we release half-baked 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. An interesting example of this is a new feature that is called Universal Publisher. Universal Publisher represents a really significant change in Yammer where you can post a single message to multiple groups at the same time. Today you can only post a single Yammer message into 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 less assumptions, and learn what's resonating with our users along the way.
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 on 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 taking an MVP approach to product development differ in the enterprise context? If so, how?
Brian: Again, my past experience before joining Yammer was rolling out traditional enterprise technologies, large ERP systems, CRM systems and these projects would take a year if not more. Part of that was the change management in the communication and the training involved in rolling out the new technology to make sure it was adopted. You have a 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 implications 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 a 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 their 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: Yes, I understand that it’s not just about the feature, but also about additional communication material, any means that are needed to implement the new features in the organization. These are part of your product and supplied to your customer, right?
Brian: Absolutely. One of the differences from the traditional model is that with one to three year release cycles, once you get the new version of the software it is a drastically new application. There are a lot of changes that have been bundled up into this new version. On the other hand, with the rapid iteration approach, you can actually smooth out the changes over times, 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 the reason 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 hypothesis 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, and 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 do improve any one of these services independently, so we can enhance one service without worrying too much about what the trickle-down effect will be on everything else. 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, are there things that 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 into. If you are selling to the enterprise, consider the various regulatory environments, your customers' appetite 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 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 who's jobs are tied to a certain feature set, they will always want that feature set to take precedent 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.
InfoQ: Thank you Brian for doing the interview.
About the Interviewee
Brian Murray is Yammer's Director of Enterprise Strategy 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.
Previously, Brian led the design and development of Yammer's structured rollout methodology, which provides a framework and strategy for customers that want to achieve company-wide adoption of Yammer's enterprise social network.
Prior to joining Yammer, Brian was a Consultant at Deloitte, focusing on change management and technology deployment in large organizations including Chevron, CVS Caremark, and Juniper Networks. He has a B.A. in Business Economics from the University of California Los Angeles.