3
1 Comment

Roadmap & Decision Tree (Day 251)

Inspired by this tweet:

Linear roadmaps are misleading without a crystal ball for seeing the future. A roadmap that recognizes the existence of risk as time goes on is more honest. But an effective PM needs to anticipate possible branches, too - and create clear criteria for following each path.

In fact, for crypto projects, the "progressive decentralization" roadmap is quite linear. It's always: build product market fit --> rapid iterations --> managed go-to-market and eventually --> community ownership.

For the APIS project, we've identified the pain point of developing for Ethereum and other blockchains (product market fit) and started to execute the "rapid iterations" on the roadmap. The decision is relatively simple. We always weight the feature that has the highest score of complexity x popularity. For example, transaction management is frequently used and has quite a bit of complexity, so it is prioritized over multi-chain support.

The last diagram--the strategic roadmap--is a classical game theory decision tree. When resources are limited and there are multiple possible outcomes, applying game theory with real data will make an abstract problem concrete. Then we can study the nash equilibrium and apply optimization techniques.

  1. 2

    rational I dunno for me it's been like this, a merge of the misleading and honest. I estimated where I wanted to be, and anticipated where I will be, although didn't see the full spectrum of opportunities. As I've progressed, I've discovered more solutions that I'm solving, and my area of influence, but stayed true to the backbone of the initial strategy. And this not even consciously but subconsciously.

    I think it's very important to stick to your plan otherwise you'll get burned out, features will creep and you'll just abandon it all. If you have a rational plan, you can see that the possibilities are going to spread in various directions, and you need to handle that in a cold, logical manner - let me get my target done first, then we can come back and work on the sidelines.

    So I'm not sure whether one should give up their initial vision for the sake of something new that came along the way. If it's useful, it will fit it somehow, but to iterate, I don't think one should deviate much from the project target.

    That's why you have waterfall and agile, and a lot of today's projects are failing when they employ agile, they see all these numerous possibilities and start playing with technology, instead of delivering the initial set of requirements agreed upon with the client (or yourself). It's a dangerous territory and waterfall with strong design is the only solution.

    Liberal stances like the last diagram, show that you're not exactly sure what you're trying to achieve IMHO and what your product is. Clear positioning is the key as it will help narrow down what 100% competitive advantages as truly yours. If you start applying the game theory, it means you're uncertain about that. That's only good when you have a lot of VC/blockchain money but you can't build stable businesses that give people jobs and security like that, again IMHO.

Trending on Indie Hackers
My year-long passion project is live on Product Hunt! Coffee Chats is like if Calendly and Carrd had a baby. 28 comments Looking for opinions: moving from a one to one, to a one to many account structure. how? 14 comments Happy to receive feedback about my new landing page 9 comments Notion API Beta is Open. What are you going to build? 8 comments I am building the first side project in public - The Struggle of Idea 6 comments 14 eBook pre-orders in the last 48 hours! 5 comments