Lean Startup Adventure, day 2: The Idea

François Zaninotto
François ZaninottoJanuary 15, 2016

In the previous post of this series, Yann introduced the Lean Startup adventure we embarked in mid 2015, and that we're documenting in this blog post series.

A product starts with an idea, but how does an idea start? That's what I'll describe in this post.


Large companies can sometimes afford creativity workshops, also called ideation workshops, to come up with new ideas. I've participated in such workshops, using tools like Innovation Games or Design Thinking. The idea is mostly the same: gather between five and ten people with various background for a day or two, and animate their reflexion so that they find, with their own business knowledge, a killer idea for a new product.

At first, quantity is more important than quality. Bad ideas are dismissed, and good ideas are promoted. The best ideas get developed in more details, and with a bit of luck, at the end of the workshop, the team has found ONE killer idea.

And most of the time, the story ends there. Finding an idea is easy, but quickly bringing that idea to reality requires a startup way of thinking, which large companies often lack. Most creativity workshops I've participated in were actually motivation workshops, an expensive way of showing to the people gathered that their ideas matter for their managers.


Continuous Ideation

At marmelab, we don't organize creativity workshops. We just note every new idea we have, when it comes up. I personally encourage sharing product ideas with the rest of the company by sharing my own, and asking for feedback. As a consequence, we have tons of product ideas. Most of these ideas come either from a joke (like "A connected plant with auto-watering via Node.js"), or from a customer requirement that can be generalized (like "A dataviz for time series").

But as we are engineers, we have more ideas of tools than products. And as we like building tools, many of our good ideas for tools end up as open-source projects.

Open-Source And Added Value

Marmelab is a regular contributor to the open-source community. We fix bugs and add features to existing projects. We also publish open-source libraries of our own - see our GitHub Account and "Two Years of Open-Source" for details. These resources are free, but they have value. They speed up development, they increase code quality and stability. Users of our libraries regularly tell us about this value, including through GitHub stars.

If there is customer value, is is possible to make an actual product out of one of these libraries? Can it be done without sacrificing the open-source licence?

What We Have Identified From Our Customers

One of our open-source tools is called ng-admin. It generates a client-side administration interface based on REST endpoints. It's very popular, and widely used. In our own projects, it saves us a lot of time by dividing the time to develop an admin backend by a factor of 3.

Vimeo might track you and we would rather have your consent before loading this video.

Always allow

As it's very easy to sketch interfaces using ng-admin, and because the REST endpoints are developed first, we just build admin interfaces interactively with the customer. For instance, the customer asks for a new screen to edit user profiles. After a quick discussion, a marmelab developer uses ng-admin to build a first (fully functional) version of that screen; it only takes minutes to wire it down to the user profile API endpoint. The developer shows the new interface to the customer. The customer asks for adjustments in naming, positioning, or the type of widget used to edit a particular field. The developer does all these changes live, and the customer is then confident that the interface is exactly the way they want.

Once, one such customer, seeing how easy it was for a developer to build an admin interface, complained that they'd prefer to have a GUI letting them build the admin interface themselves. That would save developer time for more complex features, and they could adjust admin GUIs when they want.

Well, that's a good idea.


From the Idea to a Product description

When I try to generalize this idea into a product idea, here is what I come up with.

SMEs and small business usually don't spend much time on their administration interface because they are the only users of this interface. Yet, a sophisticated admin interface is indispensable to effectively manage a business.

In addition, web startups tend to use more and more a new type of software architecture: API-centric apps. So most of the time, these companies have a REST API before they have an administration interface.

An admin builder working on top of REST APIs would allow them to save money on the development of homemade tools to manage their backend data. This would be used directly by product owners to customize the admin interface they need without any developer required.

Let's call this product "Admin-as-a-service".

Note: To be honest, our process is backwards. We have an existing tool, and we look for a customer pain point to make it a product. Instead, we should forget about our tool and work on the customer pain points first. We'll discover that later.

Next Steps

A good idea is worth nothing. If you're a developer, you've probably received countless requests from people telling you they have a killer idea. Most of them never release an actual product, because building products is hard.

We would like to know if a business is possible around the "Admin-as-a-service" idea. That’s what we are going to find out by applying to the real world, on a real case, some of the principles of the Lean Startup. Read on to see how we went further into details about this idea using a Business Model Canvas.


Thumbnail picture: Spiral Flower II, by Michael Levine-Clark

Did you like this article? Share it!