Bringing Sanity to Web3 Chaos

Experience Summary: 8 Months as Product Manager of a Web3 company

What was the challenge?

I joined as Product Manager and had to work cross-functionally on other responsibilities, like sourcing, interviewing and hiring for a brand new development team of 15 people.

The company had seen success during the latest bull run as an accelerator and ICO (Initial Coin Offering) launchpad for blockchain games, what they call an IGO (Initial Game Offering). Their own token had generated enough wealth to incubate projects and bring new games to market.

I had to manage a problematic legacy codebase, tending to annotating and tracking issues that affected more than 100,000 visitors monthly, and more than 50,000 users who actively engaged with the company's token, which features a market capitalization of over $40,000,000 USD.

On top of the traditional responsibilities of a Product Manager role, like gathering new requirements, mapping out user and data flows in diagrams and structuring tasks on ClickUp for our roadmap and backlog, I also created Figma designs and prototypes from scratch.

The main challenge was packing all of it in one day, while also keeping an eye on community feedback and the frequent changing of requirements, which would happen mid-sprint.

While building a feature that would highlight an incubated project's details, I had to make sure that every new database collection we were creating could play well with the rest of the customer touchpoints, some which were still using legacy code.

The Solution:

I made the design shown above, like all the others, with all the technical and time/effort constraints in mind. We had to be careful not to add too much, and optimize for speed, but even then we would be requested to add more features to bolster the other products.

If a project uses information in this IGO page that is also used to describe an INO (Initial NFT Offering) for the same project, we need those in a way that can be fetched from the same place and displayed correctly in both new and legacy touchpoints.

I worked with our Project Manager to make sure we could keep refining, matching and patching any incongruences with the legacy systems, while we created new API endpoints specifications that we needed for the new products. I would then test these endpoints using Postman and provide feedback to the team.

Mapping the relation of old and new, and matching this to the user stories was a great and laborious effort. As I would then lead agile rituals, it became absolutely necessary to get the rest of the company to adhere to agile software development principles.

For this, I had set a fixed weekly meeting with stakeholders in order to validate all the work and I would personally demo everything. It is something I enjoy tremendously. However, most key decision makers would fail to be present and lack the time to catch up. The reality of the Web3 dynamic is that most people move in a way that is mostly reactionary to market forces.

As a result, our sprint planning would mean nothing in the face of a sudden, arbitrary requirement change. Even things discussed and agreed before, like time for refactoring legacy code, would be undone in the whim of a moment. When I would ask about it, the terms of the verbal agreement seemed long gone and forgotten.

This is a slide I showed countless times, in a futile attempt to explain that agile rituals like Poker Planning require the consensus of the team to estimate the task difficulty. That simply throwing that away and changing it for an urgent request for which there is no time is not only a bad practice, but undermines the trust, engagement and flow of engineers.

I would ask to place these new requests on a next sprint, to no avail, so we were creating new issues as we did not have time to review and test code the proper way. We were left to do this as part of sprint retrospectives, which is a recipe for technical debt. In the meantime, we had to resort to just Kanban in order to deal with the madness of old, current and incoming requests.

This was unfortunately the theme of that company, which is why we decided it was best to part ways. But I remain proud of the work we did with process, features and new people we brought in. I wish them the very best and I am lucky to have come away with an experience that highlights the importance of strong engineering backgrounds at the top, as much as planning, design, empathy and kindness.