Nicolas Cynober's blog

Turning your business idea into a product

I recently had the chance to think about creating an innovative new product from an idea.

As a Product Manager, this is a rather rare exercise, as the definition of the original product that will enable a company to achieve its mission is often led by its founders, and this is even more the case when it's an innovative product.

This is an essential step in any entrepreneurial project, because before you take on board your first developer or contact investors, you need to have a clear idea of what you want to achieve and how much it will cost.

Since I've just done the exercise, I thought my method might help other entrepreneurs. That's what this article is about.

For the record, this is an adaptation of the framework we used at Pearltrees to design our macro-functions, right up to complete products like Pearltrees Education or Pearltrees Editor.

Here are the 9 steps I followed:

🌟 Company mission statement

I work on the assumption that your company's mission has already been defined. Our role here is to design a product that will fulfill this mission.

Let's imagine we are Leboncoin and our mission is as follows:

Givingeveryone the power to live better every day.

Beautiful.

🎯 Product objectives

There is potentially an infinite number of products that can meet your company's mission. Defining a list of prioritized objectives will be your compass and an invaluable tool in your first, structuring product decisions. For example, if we take the example of Leboncoin, this could be :

  • A place to save money by buying second-hand
  • Enable people to resell items rather than give them away or throw them away
  • Join a community working for a more sustainable world

The order is important, and will enable you to decide on difficult questions such as: should users arrive on the search for items to buy or on the addition of items to sell?

At launch, the site will be empty of any ads, and it might make sense to encourage users to sell their items first... Well, no, we'll land them on a search for items to buy (that's goal #1) and solve the "empty catalog" problem via other, more secondary levers.

🤕 Deep user needs

I'm not going to draw you a Maslow pyramid, but it's all about identifying the deep-seated needs that you're going to try to address as a priority. Saving money or time are classic needs, but you can probably supplement them with more specific needs.

If we go back to our example, I'll see:

Save money quickly and safely

As a result, we'll most certainly be highlighting the price and its evolution (now's the time to buy), the seller's distance (I'm not going to cross Brittany for a coffee table), his delivery options (because it'll never fit in my car) and his average response speed (because on Amazon it'll arrive tomorrow), and all in a protected environment (that goes without saying, but we'll still make a fuss about it).

🕵 Reference products

I suggest you identify 2 or 3 reference products to study in detail. I'll do a dedicated article on "how to analyze a product" but until then, just study in detail :

  • Onboarding: the home page, registration and subsequent steps. Focus on the content: what are they telling you? What are you encouraged to do first?
  • Product architecture: like a building, what are the load-bearing walls? Tip: as the mobile app has strong constraints on available space, there's a better chance that the hierarchy of functionalities will be more clearly laid out.

On all your observations, systematically ask yourself why? What problems have they encountered? Was this the simplest solution? What were the alternatives? Is this standard?

In our example, if we go back to 2006, when the bon coin was created, I could see a benchmark of the following solutions:

Ebay

Craigslist

Amazon

🔠 Vocabulary

The termonboarding is fairly common in product design, just like the shopping cart in an e-commerce site, but you'll soon realize that you need to name all the places, objects and social interactions to design them together.

Define your vocabulary clearly and simply, and make sure everyone knows it.

So I'm posting my adpublish itIadd it or I drop it off ?

A word of warning about communicating with your technical team: programming languages require vocabulary. Your technical team has its own naming constraints, and less flexibility than you to change them. Let them agree on their own vocabulary, but make sure they remain bilingual.

🧭 Approach

To sum up, we've got objectives, a list of needs, comparable products and a vocabulary. We could open a flip chart and start drawing, couldn't we? Just a little more patience, and I'll take you through a final framing stage.

At this stage of the process, there are still an infinite number of products that can meet the objectives we've set ourselves, so choosing one approach will considerably narrow down the field of possibilities.

Our study of reference products has shown that there are several approaches to creating a site for selling second-hand items. For Leboncoin, I'll describe it as follows:

Understand immediately that this is a corner, a sort of open-air flea market, not particularly refined or warm, where I'm going to make some quick bargains.

This approach will have far-reaching consequences for the product and the design. It will enable you to lay down the architecture and load-bearing walls I mentioned earlier, and give a direction for defining your visual identity.

A quick aside on design, as we haven't talked too much about it yet. Did you think Leboncoin was ugly? For me, its design is a direct consequence of the approach we've chosen.

✍️ Mock-up of main use case

This involves defining one and only one use case to be described from start to finish. You need to choose the user cycle that will be most critical to the success of your product. I'm not going to describe now what a good product is, but your efforts now and in the future should be focused on this user cycle.

The cycle must start as far upstream as possible and be as realistic as possible:

  • The completeness of the cycle means you won't forget anything, and you'll be conditioned like a real user discovering your product.
  • Realism will help you reduce presentation bias to people outside your project.

For example, if I put myself in the shoes of someone who doesn't know Leboncoin and Google "used raclette machine".

I'll stop at the connection request, because you've understood the principle, but you'd have to go as far as the message to the seller.

📋 Identifying secondary use cases

At this stage, you don't need to make models of the other cycles, but you do need to list them to get an idea of the work ahead.

I recommend a pyramid approach to make sure you don't forget anything. Break your product down into a few subsets and iterate. This can be bulleted lists, a mindmap, boxes within boxes... This will give you a complete mapping of your product that will be very useful in the long term.

In our example this could be :

  • Product presentation
    • Product details
      • Photos
        • Carroussel
        • Zoom
        • Etc.
      • Description
      • Delivery
      • Etc.
    • List of products
    • Search
    • Recommendations
    • Etc.
  • Social system
    • User profile
    • Messaging
    • Notifications
    • Etc.
  • Onboarding
    • Home page
    • Registration tunnel
    • Etc.
  • User support
    • Change password
    • Preferences
    • Etc.

No need to be exhaustive, 3-4 levels of depth should suffice.

⏱️ Estimated development time

At Pearltrees, we like to say that you can estimate anything in 5 minutes, even send a rocket to the moon. The trick is that there are two figures that will come out of this exercise: time and margin of error.

The margin of error is mainly impacted by :

  • The experience of the person who believes
  • Time spent estimating
  • The amount of information available

The third point is a trap, since all the information is never available. The margin of error is therefore never 0%, even 24 hours before the product release date. The trick is to iterate and re-estimate regularly when you have more experience and information available.

Who can estimate? Anyone. If you want to have your living room repainted, you can imagine that it will take more than an hour and less than two weeks, or 7 days if you cut it in half. I'm not a painter and I estimate my margin of error at 50%. The project will therefore take between 3 and 10 days.

Do the same exercise on your product, based on your main case and the list of secondary cases, and you'll obtain the number of man-days of development required, with a first margin of error.

If you're planning to release a first version of your product in 1 year's time, you'll be able to estimate whether a CTO partner is enough or whether you need to raise funds to recruit an army of developers.

For a site like Leboncoin in beta version, I arrive at :

3,125 development days with a margin of error of 50%, equivalent to 8 FTE for one year (between 4 and 13).

I calculated this in 5 minutes without listing the features exhaustively, but if the goal was to release a beta in a year's time and you're currently on your own, you'll need to either :

  • Increase resources. For example, hire a technical team of 8 people.
  • Extend the releasedate. For example, release a beta in 2-3 years that will be developed by 2 co-founders.
  • Reduce the scope. For example, limit yourself to critical functionalities at first, then iterate.

🙏 In conclusion

I hope you found this method interesting and useful? If you see any missing or superfluous steps, your comments are most welcome!

If you've made it this far, you're brave because I wasn't anticipating such a long article 🤣 Feel free to follow me on LinkedIn to be notified of the next article 🔔