I came into this class with a pre-conceived notion for product managers that turned out to be entirely wrong. Based on my previous professional experiences in companies with subpar organizational structures, I assumed that the product managers primary task was simply to facilitate their engineers and allow them to get work done. This class has taught me that while that was certainly an important facet of product management, it is only a small part of the whole, and the tasks and responsibilities governs far beyond that — something that we were intimately aware of as we had to juggle 3 different hats and complete our project.
The group project was very fascinating to me, because it forced each and every one of us to approach the same topic on a rotational basis, covering everything from engineering to communication & management to design. While I personally gravitated towards and spent most of my time on the big-picture synthesis tasks, I was glad to get the chance to explore our product at the minute level, both on the technical and the design side of things. I realized that only through a thorough understanding of the ground-level details can you truly understand the vision and product you’re working on.
Coming out of this project, however, the most valuable thing I learn was how to juggle multiple components of an overarching project together. Unlike traditional class projects that are more monolithic in nature, the deliverables in this class tends to contain multiple interrelated components that are outwardly somewhat orthogonal to one another. This meant that we had to be very careful with how we managed our time, since we had to ensure that we had sufficient capacity to cover all the components thoroughly. It also meant that we had to learn to set expectations and work in a structured and prioritized manner. While working on the project, for example, I truly enjoyed interviewing potential users and would have loved to spend the majority of my time working on that. When stack-ranking our priorities, however, we realize that the incremental value-add of the 11th or 12th user interview is not as much being able to fully realize the other components of the project, and so we pivoted our focus away.
Being able to prioritize and manage our time successfully was thus fundamental to the overall success of our project, and while I think we did a good job, there is much we could have done better. Looking back, I think we should have focused on setting incremental goals and meeting more regularly to ensure that we are on-track, instead of assigning grand tasks to each member and meeting on a week-by-week basis to check-in progress. While scheduling made it rather difficult to do the former (and is largely why we went with the latter), we realize that the small disconnects that we each had meant that some parts of our work had to be socialized and realigned at the end of every week, which is an inefficiency we could have certainly worked to eliminate better.
Looking forward, if we had more time I would like to spend most of it fleshing out our relationship with the corporate stakeholders we interviewed. We realized that the success of our business hinges entirely on companies being willing to buy-in to the product we’re developing, and why we have received verbal confirmations (“yes, we would consider buying this product”), it’s hard to be confident in our direction without further confirmation. I would love to develop and sell an MVP to our corporate partners, or something of that sort, so that we can at the very least verify that our product is commercially viable. This would be something that would take significantly longer than a quarter, however, and while regrettable, is not something I suspect we could have done this quarter anyway.
