The problem

Younger Vilva was so excited: I had hit a big milestone. I had decided on my first experiment (ByteVitae)!

Ideas started flowing like rivers. Every waking minute, a ton of features and ideas rushed to mind, and I struggled to note them all down. It was going to be the perfect product! 🙌🏻. But… here came the first dilemma every product builder has to face:

Where do I start?

All my previous startup years taught me two things: that ping pong tables are a must for any office, and that I had to start with the barest essential MVP I could think of. Easy! ...right?

I could (should) have done a validation MVP. For example: Creating a landing page and delivering manually designed CVs and the like. But I purposely skipped that phase and focuses on building a coded product from the start. Shame on me.

So where do you start?

With this in mind, I ran to find anyone around who could help me further develop my idea. And luckily for me, being in an environment like "La Cova" ensures you are constantly surrounded by experts in some area or another.

Including product people...🤔. So I harassed them a bit, and eventually we got together to define my MVP.

Note that I could have decided a few features by myself and start building straight away, but remember that your journey is as much about honing your personal skills as it is about creating products. And I really wanted to learn how to do product management like the pros. I had done PM in the past and… let's just say the experience was far from ideal.

My first step as finding help, and your first step should be too. (Of course be better than I was and make sure to validate your idea before any of this.)

Makoto to the rescue!

I had the immense luck of working with Makoto Squad while building a product during my time at Devscola. Makoto Squad made the product development process look organic and surprisingly blockage free. In the end, it really showed in the quality of the product and especially in the development experience. A far cry from my own past experiences, where everything was a cocktail of chaos, incorrect estimations, stress, and occasional shame.

They were kind enough to hook me up with some of their workshops to learn Product Mapping and User Story Creation. After learning some new tricks, we were ready to start.

⚠️ Shameless promotion: If you are part or in charge of a product team and you want to improve your process and techniques consider hiring these guys. Or at least try to attend one of their workshops.

I have zero bullshit tolerance in my posts. If I didn’t like them, I wouldn’t recommend them. It's a small thing I do to try to pay them for the invaluable help they gave me for free. Hopefully, this post goes viral and their site crashes. 🙏🏻

The methodology

Metho… what? In the past my way of defining a project included these steps:

  1. Decide a few features I consider are important
  2. Code

Sound familiar? 🙄 It’s a pretty common “methodology” techies tend to use because we CAN'T WAIT to start coding.

Well, not surprisingly, it’s much easier and the result is much better if you follow a “real” methodology. I'm going to try to explain very simply, and in my own words, the process we went through. I have no doubt that this is more formally explained somewhere else, but I have no clue where. Let's hope you can learn from my experience, indie hackers.

Step 1: The Pitch

We gathered a group of five or six people and gave them my short ByteVitae pitch:

  • A tool for developers to create and keep an up-to-date, great looking CV in a fast and easy way.
  • You can link third party services to gather information.
  • You can export it to PDF.

Step 2: Gather Ideas

With an image of what your product aims to be, everyone (including yourself) should take a few minutes to write down benefits or qualities of the product in post-its. Anything is valid here. Go wild; you can prune, pare, and cut later.

We got a few more out of frame.

Fast - Github Import - Export to HTML - If I pay I get my info online - Manual info - Downloadable - etc...

At first glance, this step feels really silly; you and some mates, slamming Post-Its to a board, yelling about things you think would be cool. But, that’s the best part: by involving other people in your creative process, you get fresh ideas. You tend to be too dependent and biased by the idea in your mind. So, you can get real gems out of this process just by involving someone else.

Step 3: Group Your Ideas

With all the items laid on the table (whiteboard?), the next phase was grouping the related ideas together. Basically, stack post-it notes together for ease of use.

This will make the core areas of your product shine. In ByteVitae's case:

  • APIs: 3rd party info providers
  • Export: How is the generated CV going to be exported/given to the user?
  • Security/Authentication: What kind of auth is the product going to implement
  • Payment: Payment services, models, etc.
  • Data gathering: Is the user going to input data manually, obtain it from a 3rd party’s API...
  • User Types: User/Subscription tiers
  • Templates: What kind of templates will the users be able to choose from?
  • Devices: Where is your app going to run? Web? Mobile? TVs? IE6 🤭?
  • Language: Internationalization

As you can see, many of these are common to different projects. For example: Auth, Payment, User Types, Devices, and Language are common to many SaaS products. But for me, the coolest ones are the rest; they tend to define where your value proposal is.

Step 4: Plotting Scope in Your MVP Graph

The next step was to take all that info and plot it into a graph.

The functionality areas will be the axes of a spider web chart (radar chart, technically) and the Post-It items will make the different steps on each axis progress/complexity.

This is where the process’s strength shines again. Since it makes you order your data incrementally in terms of complexity/cost of development, it almost forces you to streamline. Also, if you find yourself adding more items to the spider web, don’t worry: it's natural that more items will spontaneously appear and fill in the missing gaps. In fact, it’s kind of a good thing: filling in these gaps gives you a more complete image of your product.

(BTW we did all of this with a marker and paper originally. We just took the time to clean it up afterwards and convert it to digital to hang on my wall.)

You can get an Illustrator template for this here.

With everything plotted out, it’s simply a matter of going axis by axis and deciding where you want to commit. The idea is choosing an axis and finding the simplest step possible where it gives value to the user. The further up the axis you go, the more difficult or nebulous that benefit becomes. This helps define the simplest MVP possible; picking the simplest, easiest, and most beneficial features of your idea.

Once you have decided each step, join the points and voila! The area inside your shape is your MVP! This means that, to begin with, all you have to do is offer those steps inside the shape.

I loved this technique. Having this at hand gives you a really good picture of the scope of your project. Once you have developed your MVP, it will be a matter of growing that shape. The coolest added benefit is that you always have a clear picture of where the focus of the product is or where you’re neglecting.

Step 5: Time To Get SMART

Besides the MVP graph, we needed a definition to keep ourselves in check. There’s no better way than defining it with S.M.A.R.T criteria, so we can ensure that the MVP follows our expected rules and that we didn't miss anything. If the MVP doesn't fulfill this criteria, then it isn't finished. For those unaware, SMART stands for:

  • Specific
  • Measurable
  • Attainable
  • Relevant
  • Timeboxed

We’ll go into what each one means for our MVP below.


  • We have a web product in English.
  • User can generate a CV, introducing manually his/her data and extract it from Github.
  • User can choose a basic template or pay for a premium design.
  • Can export it as PDF.


  • A user can download his/her CV with info from Github.
  • A user can include manual info in his CV.
  • A user uses a basic template for his CV.
  • A user can export his/her CV as PDF.


  • I see it as attainable.
  • The highest risk resides in the connection with Github.
  • The second risk is my lack of experience in backend development.

This made very clear where to focus the initial development/investigation phase.


  • People will pay for a better design
  • Automatic integration of 3rd party info gives value to the user
  • Validates that I am capable of developing the integration


  • 4 weeks for development
  • 1 week for monetization

Stage 6: Drawing The Product Map

Click here to see ByteVitae's full product map.

The result of all of this is The Product Map. It is a living board that evolves as your product does. Like the MVP graph, it gives you a big picture of your product. Also, it ties together Marketing, Business, and Developing, and it’s extremely useful for defining user stories for developing.


  • Could I have defined my MVP without this process? Sure.
  • Would I have such a clear picture of the scope of the project? Nope
  • Would I have such a rich pool of features/ideas to further grow the product? Nein
  • Would I have evolved my product defining skills? Definitely not
  • Would I have a cool-ass looking spider graph on my wall now? Probably not
  • Was it worth the handful of hours we invested in the process? A big YES! 🤟🏻

This process isn’t the silver bullet to your MVP problems, I know. I’ve shown a lot of flexibility and areas for personal choice. But that’s a good thing! In the end, YOUR MVP is going to have to be YOURS. It works best if you follow your own script. I’m just here to give you an idea of what I think is your best bet to crib from. Feel free to leave a comment below if you’ve used this method and found it great. Or, if you used it and couldn’t get it to work (ie. not your jam, too many steps, afraid of spiders), tell us in the comments below anyway. Good luck on developing your MVP, indie hackers!