During this semester, I took away several insights about the discovery process. Most significantly, in-person interactions are incredibly valuable in interviews and lo-fi tests. Our in-person conversations (vs. over the phone) allowed us to observe body language and encouraged us to dive deeper into uncovering the nuances of their behaviors, their unmet needs, and how they prefer to interact with their apps. Similarly, conducting our lo-fi test 2 in person (vs. lo-fi test 1 which was entirely over email) allowed us to observe nuances on how our subjects made decisions regarding their wellness schedules. Furthermore, we were able to draw out more personas; for example, one woman volunteered that she was an athlete who had always regularly worked out, but she hadn’t figured out a way to make that happen at HBS.

​

Additionally, we learned to be very specific about what our lo-fi tests were testing. In lo-fi test 1, we chose activities for subjects, chose where to schedule them, and even added a social component. The resulting feedback was tricky to peel apart; we couldn’t quite tell which aspects of the service were appealing vs. which weren’t. Our lo-fi test 2 was simple: we tested if advanced planning would increase follow-through. While we guided subjects through the planning process, we let them make all the decisions on what to do and when. The resulting feedback was much simpler to understand. Separately, in future tests, I want to create a better mechanism for ensuring that subjects provide feedback. Emailing follow-up questions didn’t yield a high response rate.

​

In future product discovery journeys, I would aim to settle on an unmet need more quickly, and then spend more time iterating on different types of solutions. We did a good job of uncovering a diversity of unmet needs in our interviews, but then had less time to focus on exploring a large variety of solutions to address the one need we landed on. I’m happy with the solution we derived, but having tested 2-3 distinct solutions would probably have uncovered some interesting tidbits that would help inform the final product.

​

Our lo-fi tests informed two key changes to product strategy, both of which allowed the user to have more ownership over their schedules. We initially aimed to eliminate all the mental barriers to having a wellness routine by providing users with a pre-planned schedule of activities. The feedback from lo-fi test 1 was lukewarm; while having wellness activities in their calendars was a helpful reminder to do them, the activities often weren’t quite what they were interested in, or didn’t make sense to be in certain spot in their schedule. From this feedback and learning from an HBS/HKS study on ‘plan-making prompts,’ we hypothesized that guiding users through the planning process but letting them be the decision makers would be more appealing. Feedback from lo-fi test 2 validated this hypothesis.

​

We also learned that it was impractical to expect our subjects to avoid any conflicts with their pre-planned wellness activities. The main feedback we received from lo-fi test 2 is that users frequently had conflicts arise, and wanted to be able to easily move their activities around. While we had previously suspected this would be an issue, we are now including the ability to identify and resolve conflicts as a key feature within our MVP.

​

More generally, PM 101 drove home the concept that ‘simple is superior.’ When I initially conceptualized the idea of [+energy], I wanted it to accomplish every possible goal: provide curated content, allow users to save new content, give access to local class schedules, allow users to interact socially, etc. My instinct was that the more features an app had, the more valuable it would be. PM 101 reversed my logic. I now understand that whittling down to a couple core features (in this case, walking users through the scheduling process) allows PMs to ensure the app is truly addressing the core job to be done. Features that are built on top should be carefully staged based on the complementary value that they provide.

​

The most unexpected outcome of PM101 is that whenever someone introduces themselves as a Product Manager, I’ll never know exactly what they do! Through our classroom guests, I learned that each PM role is unique, and depends on the level of technicality required and the stage of the company. A PM at Google in 2017 is likely have a very different role than a PM at Uber in 2012. Nevertheless, all PMs operate on a common mission: to translate business needs and desired user experiences into a technical product.

​

While the common mission of a PM resonates with me, at this point I believe that a product-focused founder is a better fit. In comparison to a PM who may focus solely on changes in user experience, being a product-focused founder guarantees the need for me to connect the dots between large strategic decisions (e.g., monetization schemes, business partnerships) and the technical product. Nevertheless, I’m eager to learn more about what it means to be a PM as we go into the development journey, and maybe PM102 will change my perspective on my ideal role!