← All Posts
The Product Dies at the End
What I learned from the year I spent managing a nonexistent product #
Up until July, I was product manager for an online mastery and testing platform for students preparing for college entrance exam. This is the story of how the product died, and what I learned from it.
I was working on an online mastery dashboard and testing platform for students who are preparing for college entrance exam | Photo by Bonnie Kittle on Unsplash
Up until July, my official title was “Product Manager”, and my job was to, well, manage a product. The product was supposed to be a spin-off of a project we had already finished, it had numerous potential users, and it was in an area I’m familiar with and ~passionate~ about. It was beautiful, just like every other failed plans out there.
Long story short, it didn’t work out. I overshot the scope of the product and it became a promising concept that consumed a lot of resources we didn’t have. I would know, because for months, we tried. The potential users did not become actual users, and I spent months adjusting concepts and fixing CSS and basically perfecting things that didn’t matter.
Then finally, after months of no actual progress, the product — once dubbed my baby — was officially shut down. It was unceremonious. Three people, closed doors, a short explanation about company growth and how other products were growing with it, then an even shorter one about how my product wasn’t and therefore had to be cut. There wasn’t a discussion, there wasn’t a review, or feedback; there was only mutual understanding that the product died long ago and it just took too long for someone to call it.
Anyway, life is a series of pain we continuously learn from in hope that it’ll hurt less, or something. So here are my notes from the experience. A disclaimer before someone comes at me for writing an uninteresting piece on Medium: some of these lessons learned might be something completely obvious or plain stupid to point out.
Understand What You’re Doing #
TL;DR: Define your role, do things that are your jobs and delegate things that aren’t.
When the idea of the product was pitched to me, I had just finished grad school, still drunk in my ideals of what the ed-tech scene in Indonesia could be and how I was going to be one of the people defining it. I hadn’t decided on a job because my arrogant ass wasn’t interested in any of the existing ed-tech startups. So when I was offered the product manager position with full control of what the product would be, it was the opportunity for me to do what I want.
Exciting as it was, I was and always have been (also still am) a puddle of self-doubt. I had no experience in project management, confidence in leadership, or an actual dedicated team to work on this project. I was skeptical; I thought it was ambitious for the company to try to go from one product to four within one year. But I guess if you want something you never had you have to do something you’ve never done, or something, also big risk big reward, or something, take the leap of faith, no pain no gain, etc, etc. Anyway, despite having no clear idea of what I would have to do, I accepted the offer. I was product manager for project Pegasus.
There were a lot of things to do; from examining the project we were using as the base of this product, gathering insights about what features would be relevant to the project while still fulfilling users’ needs, finding ways to approach potential users, framing the problem and solution into a beautiful pitch deck so stakeholders would be interested, actually scheduling a meeting with said stakeholders, etc. It was already a long list even before I included the development of the product, which, with the concept we were going for, had student-facing, teacher-facing, and admin-facing interfaces. It was overwhelming.
I guess it was human nature to start with what you know. I knew how to do user research and competitive analysis, I knew how to make a presentation, and I knew front-end development, so that was what I did. I also learned a lot of things I didn’t know how to do, like designing and arranging presentations so it’s not a drag to listen to, approaching clients and conversing with them, making timelines and a roadmap for a product, etc. Overall, I did a lot of things, most of them likely out of my scope of work.
Looking back, I probably should have started by defining my role and writing down my responsibilities. I should’ve had a list of things that are my job and list of things that aren’t. I should’ve done more research, read more, asked questions, maybe even sought help from people with experience in product management. One, this would’ve made it easier to keep track of the things I need to do and things I need to delegate, and two, this would’ve helped me prioritize which action items I should be doing first.
Respect the Data and Adjust the Plan #
TL;DR: It’s okay to change plans. Be realistic and prepare ideal, good-enough, and worst-case plans.
As a self-proclaimed UX researcher, I tried to do it right: I started with the user. I was unable to sit down face-to-face with our potential users, so instead I used a Google form to collect data. At this point, I had finished examining the existing project and already came up with several enhancements that I thought would be interesting to have. What I realized later was that I wrote my survey questions already knowing what I wanted the product to be. As a result, the questions were more about proving that the product (along with the features I already planned) was worth building rather than gathering insight of what the users really need.
In addition to the survey responses I gathered from students, I did a couple email interviews with teachers to learn how things currently work and how the product would fit into the system. From both the surveys and the interviews, I learned that an online platform is something that would help and is interesting, but it was hardly an urgency. For Pegasus to be relevant, it had to be able to facilitate back and forth between students and teachers, or it had to be able to deliver information in an instant, a.k.a. be a mobile app.
Nevertheless, we pushed through with the plan. At that time, the product team included a designer, a back-end developer, and myself as the manager and front-end developer. None of my team was dedicated to the product; we were all also working on client projects. I knew that I wouldn’t get a mobile developer any time soon, but I did include mobile development within our road map — I think I put it on the sixth month, after the web platform was (supposed to be) stable. Now that I think of it, maybe I didn’t make the right adjustments; maybe I limited myself and the product by having specific features too early in the development, and failing to rework these features according to the data from user insights. I should’ve adjusted based on user needs, but instead I adjusted the product according to our limitations.
Fast forward a couple months, we had a promising negotiation going on with one of the organizations we approached. However, our company was doing well and consequently there was a flood of client projects coming in. We didn’t have the resources to progress according to our timeline, and the backlog kept piling up. Pegasus was still the massive system that it was, and we were still the small team being overwhelmed by it. It would’ve been good to have a three-tier plan: an ideal plan, a good-enough plan, and a worst-case plan. When targets aren’t getting done, I should’ve adjusted the next target instead of trying to accomplish two targets in the span of time designated for one.
In retrospect, I basically should’ve been my normal self and be a realistic, borderline-pessimistic person. I think I was busy trying to prove to myself that it was a good plan, and if it was a good plan, then it should be easy, or at least feasible to execute. I guess my lesson learned in this is that changing plans isn’t necessarily a bad thing; it just means that you miscalculated your resources and capabilities, and you’re updating the plan according to new calculation and experience. Maybe you overestimated yourself and your team, maybe you took on too much for one sprint; that’s fine. But now that you know that it was an overestimation, adjust the damn plan.
Communicate Problems and Expectations #
TL;DR: Communicate properly, and address problems early. Don’t keep your problems to yourself just to avoid arguments.
There were some obvious problems with the development of Pegasus. Overall, we were definitely short on human resources. At some point, our designer had to go on maternity leave and so I had to wait for other designers in our company to be available if I needed anything designed. It slowed down a lot of things, maybe more than it should’ve. I couldn’t continue with front-end development, I couldn’t complete my new pitch deck, and it stopped me from finishing proposals. At that time, the development for the system was also going very slow. We had a lot of client projects going on, so back-end development kept being postponed.
It probably wasn’t a huge deal — my proposal could’ve done without visuals, I could’ve opened up Illustrator myself and create a mock up, I could’ve made something up for front-end and finish everything so that it would be ready when the back-end is. But I was already losing my motivation. The backlog as well as lack of progress were also huge hits to my confidence about finishing this product.
There were times that I felt at a loss, wishing I had someone to do some of the things I was doing, or just simply discuss the product with. I was looking for support, but I never really said it when I needed it. I’d mention it during quarterly meetings, or when someone asked: that I was overwhelmed, that I needed help; but I never truly pursue it. I could’ve (and should’ve) been better at communicating my problems and expectations.
I’ve never been comfortable asking for help. It had been a problem in the past, and it was definitely a problem while working on this product. I didn’t want to keep following up with tasks because I didn’t want to be a nuisance to the people who were obviously busy, but to be blunt, they were a nuisance to the product for not delivering. I want to be very clear that I’m not blaming others for this; this is my lesson learned: you don’t need to care about inconveniencing other people. When your duty includes making sure the product stays within timeline, it means you have to make sure your team get their deliverables on time. Your team being busy with other projects is not your concern; it’s their job to manage their own time.
Overall, I wasn’t vocal enough about my limitations, problems, and expectations. I didn’t address problems early enough, if at all. I let a lot of problems drag on instead of properly communicating, because I wasn’t interested in arguing with anyone. From this experience, I learned that if I dislike or disagree with something, I should say it. Don’t be passive-aggressive about it, don’t make it come off as a joke; say what you don’t like, explain why, and communicate what you expect. Don’t keep problems to yourself just to avoid arguments.
Facilitate Teamwork #
TL;DR: Involve your team in managing the product — ask for commitment, invite everyone to learn what everyone else is doing, check-up and follow-up.
Despite having a team to work on this product, I didn’t give us a chance to act like one. I didn’t involve the others in the research process of the product, mainly because the team wasn’t assigned until after the concept for Pegasus was fixed. Even so, I could have facilitated a session with the team (once it was formed) to discuss the product we were going to build and see if people had any feedback about the planned features.
I especially feel like I failed in building a sense of ownership in the team; Pegasus felt like just my product instead of ours. The team felt like some people who executed the plan I made for an application I wanted, and I never really took the time to ask them if they liked the idea of the product or even wanted anything to do with it. More importantly, I never took the time to ask for a commitment; to form a mutual understanding that we all needed to do our part if we really wanted to finish this product.
Now that I think about it, I wish that I had some kind of system to keep track of what everyone was doing and consequently how the product was doing. I probably should’ve adapted a project management framework to scaffold communication within the team. I should’ve translated my road map into weekly deadlines with specific action items and hold someone responsible for each one. Furthermore, I think it’s necessary that everyone in the team know what everyone else is doing , so make time for check-ups or stand up meetings with the team, and do proper follow-up. And set specific deadlines — never settle for a vague “Okay” when you assign a task.
In hindsight, I should’ve involved the team more in managing this product. Knowing how the product is doing would help everyone in the team realize how they’re doing in regards to the product and its timeline. These discussion can also be a medium for everyone to share the problems they encounter or provide assistance to someone else’s problem. And I think most importantly, meeting the team, sharing your problems, and realizing that everyone’s working hard for the product would help keep your motivation up.
Take Your Time to Make Decisions #
TL;DR: You’re allowed to take time to really think about your decisions. When it comes to third parties, don’t burn bridges.
There were naturally numerous decisions that I had to make over the course of developing this product. At one point, I was asked to also include another past project into the product: a video-based online learning platform with mini quizzes after each video. If you’re asking why, then same. It was within the same vein of education, so it made sense to research and market both together. It was then called project Phoenix.
It was appealing on our pitch decks, because yay more features, but the lack of resources was worrisome. Nonetheless, I adjusted the year-long plan to also include development for Phoenix, but I hardly did it justice: I didn’t do as much research as I did with Pegasus, didn’t go to users, and didn’t do proper competitive analysis. Phoenix stayed true to its old form, only with an added layer of mastery and possible integration with Pegasus (which would have been a huge thing to develop). I also planned for Phoenix to be finished around the same time as Pegasus. See the problem? I have nothing to say for myself.
I was never as excited about Phoenix as I was about Pegasus; it just felt like extra work. Thinking about it now, I honestly wonder what I was thinking and why I agreed to this. I think I was already overwhelmed with Pegasus, and when Phoenix was added to the mix, I didn’t really want it. In retrospect, I should’ve thought about it thoroughly and formed a coherent argument about why not to add onto the workload we already had for Pegasus.
Another big decision I had to make was when I decided to drop the promising negotiation that was going on for Pegasus. At the time, we couldn’t agree on the ownership and cost of the product. The last meeting I had with their board of directors also left me feeling personally incompatible with the way they work. In the end, our team agreed to not follow-up after the last meeting.
I don’t necessarily regret dropping this opportunity, but it does make me question if I handled things right. I especially wonder how much my personal judgement about their management affected my decision. What if we actually could come up with a win-win solution if I only let go of my personal feelings? I also wonder if not providing proper follow-up was the right decision. It would’ve been easy to come up with a decent statement explaining that we couldn’t agree with their terms and had to therefore terminate the negotiation. But I didn’t even do that. What if we stumble upon new collaboration opportunities in the future?
In retrospect, I realize that I always thought that for every questions asked to me in a meeting and every decisions I was asked to make, I had to have the answer right then and there. It never occurred to me to ask for some time to really think about it. I also tend to feel unproductive when I do nothing except thinking during my work hour, but I realize now that taking time to think is a justified use of my time.
Additionally, when it comes to external parties, I learned that I shouldn’t make the decision personal. It’s important to assess the personalities you’re going to potentially work with, but it’s also important to make sure that it doesn’t cloud your judgement. I also took notes not to burn any bridges with the decisions I make — you never know who you’re going to cross paths with in the future.
I wish I could tell you that my first venture into product management resulted in a billion-dollar valuation with Series-A funding, but it wasn’t the case. I was a rookie making rookie mistakes, and the product(s) died in my hand. It hadn’t been the best experience, but I did learn a lot from managing this massive baby. I still truly believe that Pegasus is a good idea that could be successful with adequate resources, and I hope that the next time I get a product management opportunity, I could apply these lessons learned properly.
RIP Pegasus (& Phoenix), it was one hell of a year.
Originally on Medium