I quite like applying lean startup methodology when it comes to building a product or even a feature. Yes, I said feature — meaning, when something is part of a much bigger product, like Microsoft Visual Studio or Microsoft Windows for example.
Running lean not only will help you stay focussed on what it is that you want to build, but it also begs you to answer the question — why is it that you want to build what you are building.
Minimum Viable Product
One of the core components of lean startup methodology is to build your MVP — Minimum Viable Product. Eric Ries talks about MVP in his The Lean Startup book as:
The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. — Eric Ries
And Ash Maurya describes it even better:
A Minimum Viable Product is the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back). — Ash Maurya
However, this all sounds great if you are building or experimenting an entirely new concept/product that you need to validate to prove customers need such a product.
What about when you are building a new feature that is part of a much bigger product? How does MVP apply in that case?
When you are building a feature that is part of a well established product, chances are that that product already has a ton of data on how customers are using the product:
— What they like?
— What they don’t like?
— How they use the product?
And, not to forget that you & your feature will be part of many different teams that are building different features for the same product.
And, with well established products you are always faced with strict deadlines (i.e; you are part of a shipping vehicle), market conditions, customer expectations etc.,
Minimum Marketable Product
In these situations what you are looking for is Minimum Marketable Product (MMP). MMP can help you to build your feature so (1) you can release it to the market quickly with the right ingredients, and, (2) get feedback & iterate on it quickly.
What is the difference between MVP and MMP?
Roman Pichler sums it up very well:
The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. The MVP helps you acquire the relevant knowledge and address key risks; the MMP reduces time-to-market and enables you to launch your product faster. — Roman Pichler
Disclaimer: The following example does not describe how features/products are built within Microsoft. This is just my experience in building a feature that has worked very well for my team.
— If you are interested to know how Developer Division at Microsoft builds software, I recommend reading this post — Scaling Agile Across The Enterprise.
— If you are interested to know more about the Program Management role at Microsoft, I recommend reading this post — PM at Microsoft.
When I started building the Office 365 API tooling for Visual Studio, I know I wasn’t building an entirely new stand-alone product to allow developers consume Office 365 services in Visual Studio.
There were few things that we (as in my team) already knew (unlike in a traditional startup world where you pretty much start from nothing):
- Product is backed by the Office 365 API service which is released as ‘preview’.
- It was more of a ‘feature’ as it is built into Visual Studio.
- Office 365 APIs currently available in preview is comprised of a set services (mail, contacts, calendar, users, groups, files, sites)and the assumption is tooling will help developers connect and consume one or more services.
- There is already a UI in Visual Studio that developers go to consume cloud based services (like Microsoft Azure Mobile Services, Bing Ads API etc.,)
- Since this is a new tooling feature, we know from data & feedback, that developers will depend on the tooling for them to get started with the Office 365 APIs.
- Initial target audience(s) will be: SharePoint developers, Office 365 developers
- Initial applications to support: Windows Store Apps and MVC Web Applications — Our initial focus was to help developers build device applications. However, we also decided to support web application developers and started with MVC web applications (again, based on data for new web applications in Visual Studio).
So, there is an expectation of what Office 365 APIs are and that your product should respect them so developers are able to do what they want to do with the Office 365 APIs.
If we had taken the MVP approach, we would have approached it in a different way. For example:
— Instead of supporting all 7 services in the tooling, why don’t we start by supporting just one and see how customers react and use the product?
— Instead of also supporting web applications, why don’t we just support Windows Store apps, get feedback and see if customers are interested in consuming Office 365 services in other applications?
If we had chosen to build a MVP, we would have minimized what we are building as much as possible as the goal will be to learn, build, measure, and, pivot early if necessary.
What about MVP then?
Just because you choose to build a MMP, doesn’t mean you can ignore MVP.
Even when you build a MMP, you may break your feature into different experiences and build a MVP in each, especially when you are unsure how customers would react to a particular component. For example:
We did not build a publishing experience in the tooling as the services still in preview are not supported in production and we wanted to get feedback from developers to know how they use Office 365 services using the tool to build the right publish experience.
We started building the tool with absolute minimal capabilities (on what developers can do) to start with yet pack with the rich features that enable developers to discover and consume Office 365 services in their Visual Studio applications.
That is what I call a MMP.
So, did we succeed?
We have so far released 3 updates (in the past 3 months), iterated on the design, user experience and even supported a lot of applications (device, desktop and web) based on customer feedback. We are also in touch with few customers who are giving us tremendous feedback.
There is still work to do, but I am confident we are moving in the right direction.
If not, we are ready to learn from the mistakes and pivot if necessary.
I can only stress how important it is to get feedback.
No matter what methodology you choose — MVP or MMP, it is absolutely important you get feedback from your customers. There is no other way to improve your product or build something that your customers love!
↪︎ Build->Measure->Learn ↩︎
When your feature is part of a well established product, especially in large enterprises, try applying a minimum marketable product (MMP) methodology where your focus is to understand the existing product landscape, quickly build/iterate on the feature and reduce the time to market.