From Idea to Production

The idea of a product manager (PM) initially sounded incredibly redundant to me since I felt like software moves much faster when there are fewer constraints, standards, some kind of "story points" or “Jira tickets“ which I still highly disagree with. Working by myself or with other engineers in a team with no PM sounds much more flexible, and productivity increases more.

However, when I started working on Mygrid, my first true large-scale project or "startup," I realized that I actually needed to care about other aspects of an enterprise product now. The business, the customers, the cold emails, all kinds of skills that I am wholeheartedly lacking in. I can't just do whatever I want to do anymore. No more improving a query latency by 5x or randomly refactoring the codebase since it has good "code standard." Now, all that matters is whether the customer needs it or not. Working on a business solution means that you need to solve a problem and just do it really well. That is my motto for building software solutions for actual customers now, not just some guy that randomly forked my GitHub repos.

The role of product manager finally makes a little bit more sense now. A software team needs a todo list and someone needs to make it. That person shouldn't be the software engineer since they will probably go into a rabbit hole of different features or solutions that they can build. Then, the todo list is just a variety of solutions to problems that have not been confirmed by the market or the customers. The team would likely waste a bunch of time building, and although they can ship really fast, 90% of the shipped features are not what the customer needed. Therefore, here comes the PM. The person who is going to write that todo list for the team in terms of what problems they are solving and stick to only one appropriate solution for each problem. Then, we quickly validate that solution; if it is not what the customers are needing right now, we move on to a different solution. We repeat this until we find the solution that the customer actually needs and it is a real pain point for them. Then, we can finally think of all the varied changes or features we can add to this current solution. The team now spends less time just building irrelevant tools and can focus on providing the best solution for the customers' problems.

However, we are a startup at Mygrid. We don't have the money to hire just one person to make a todo list. Thus, I tried to take on this role by myself. Firstly, I needed to find a unified planning tool so I could effectively communicate all the requirements and bullet points our team needs to do. Linear was the perfect approach that I found for a small team like us with a viable free tier. It is truly one of the few software products that is just so well-designed and intuitive. Highly recommend any team to use Linear in their planning process.

Moving on, process diagrams are also very important to standardize any workflows and features that exist in the product. I find that making process diagrams is truly one of the most satisfying engineering problems since there will always be many solutions or diagrams to deal with a hard and complex problem. For example, how do we ensure that our sync engine can consistently persist any newly added nodes and information despite network failures? Making a workflow diagram is just another way to visualize your thinking, and the diagram is delivering your thinking to everyone else on the team. I hope that makes sense. I tried to use BPMN (Business Process Modeling Notation), a standardized notation system especially for making business processes. However, this tool is very limiting in a software architecture context with its lack of object notation as well as support for software tools' representations. Another alternative that I found is Ice Panel, which is a diagram tool especially for software use cases. The product is great for explaining software systems to other engineers.

However, this tool lacks the standardized and universal communication approach that BPMN has. This is one of the few reasons why we want to solve this pain point using Mygrid canvas. Instead of just the usual nodes and edges components that are currently in production, we are starting to develop a canvas for business analysts and consultants to easily generate, maintain, and share any business process with stakeholders. We are planning to start with just BPMN diagrams first for the vertical use case of BA and consultants and gradually expand to other verticals in software or financial sectors.

Did you recognize the same old mistakes that we are making? Yeah. We are building features without any customer validation. We have no idea whether some BAs or Consultants will need this or not. Assumptions are all we have. To avoid this mistake, it is time for cold outreach. LinkedIn, X, Gmail, you name it. I researched about doing campaigns on all of them and decided to use LinkedIn first since it is easiest to set up and the free premium tier on LinkedIn lasts for a month.

In the meantime, a simple landing page with a few Call-to-Action buttons and a One-liner is also my responsibility. You can't talk to potential customers without at least a sample or main message of the product.

As you can see, the idea still has not reached production and it would probably take a lot more time. Our team can't move like those Indie Hackers who have five different 6-figure ARR SaaS products. Nevertheless, I like this approach more when we are solving a potentially hard and frustrating problem for users and gradually improving it more and more by just getting more feedback and interviews.

So yeah, I lied in the title, it is a long road until production. I hope you can learn something from this blog about building a software solution and follow to learn more about our journey at Mygrid.