Heads up: This post is 8 years old. My thinking may have evolved since then — read it with that in mind.
Stay Home Dad Becomes Product Manager — Part 4#
2018–08–03
Handling feature requests. Designing 3rd party features before your own company’s product. How to decide what features to build first? FINALLY! This is NOT another post about feelings and ideals and stuff. This is the story of how I prioritized the designing of features while the boss needed me to fulfil some other obligations. Read on.
OK… Where the f$#k do I go from here?
So this request actually happened on day 1, when Lamont talked to me about stuff he’d like to hand over to me. One of which was a partner’s app, the partner is a friend, she’s going to be a mom and is super passionate about one specific thing in parenting, and she wanted to make an app on just that. I don’t know what was the deal between the parties, but Oyalabs ended up developing the partner’s features into our own app. It wasn’t pretty, and now I’m supposed to pick the project up and make it better. However, I quickly figured out that the priority was with the research app needed for the Hong Kong University study. Not only was there a deadline and specific feature requirements from the principal investigator, but also strategically for the company, I could see that it will lead to us becoming the “gold standard” app used by speech pathologist and researchers, which will give us a steady income, a small customer acquisition channel, and authority in the eyes of the consumer.
So for the first 6 weeks, I concentrated on the research app. The 3rd party stuff was put on the back burner, but I had talked to the partner on the phone a couple of times to clarify what she wanted, and I had been thinking about it, as I wrote in week 5:
“I’ve also been thinking about how to revamp the content consumption experience for a 3rd party partner, so I have some idea of how to make our own activities stream much more engaging than a list of picture and words.”
Once I was done with the research app, I jumped right into designing the flow for our new commercial app, with our partner’s content in mind. My thinking was that I could take this chance to think through how a 3rd party content provider’s material can be presented in our app. This way I could also think about the future of our own commercial app, which we sorely needed. You can probably see that this isn’t ideal. I saw it too, and this was the usual way I handle these situation, I make the best of it. I tried my best to take the chance to design our own app’s mechanism. However, I’ll have you (and myself) know that it doesn’t work.
DON’T DO IT!
I thought I had created some great workflows and designs — how users will discover 3rd party content sample in the main feed, what kind of content is in the main feed, how users can purchase 3rd party contents, how they can choose specifically to consume what content. But all the while, I had an uncomfortable feeling in back of my head — “what do we really need to put out first?”
I had dropped down to the UX, user workflow level of things, without first thinking about what users really need.
Besides my own concern, there was also the push from the partner / client. “Why has it taken so long? I need to know the costs and timeline ASAP.” She told me about her concern that her app is not her own, and her test users asked why? And that her users specially ask for direct, easy to search for content. I told her candidly about how I viewed our situation — I’m designing her content to be mixed in within our app, much more friendly and interesting than the “direct teaching” tone of the materials she gave us, it’s going to be soooo great! I understand her concern about being inside another app, but the pros is that she’ll get to leverage our marketing efforts and be exposed to so many more users than if she was to go at it alone. If after the contract period she decides to go solo, she would have established a big user base to launch her standalone app. That was my honest opinion, even though developing her product wasn’t really what I wanted.
Still, my high expectation of our first product Vs. the partner’s requirement of quick delivery, means that something have to give. The next week, I shared with the dev and design teams my initial design, their response was there simply wasn’t enough time. Also, they questioned whether or not the “client” wanted my version because their last experience with her was she just wanted what she had in her mind. Fair assessment. And just the fact that we couldn’t complete an integrated version in time meant we needed to change direction. I quickly called the partner to discuss the situation, namely we’ll need to go with a standalone app in order to meet her deadline. She was ok with that, and so, a huge weight was lifted off my shoulders!!
Again, I thought I was doing pretty well designing an integrated version, even though it felt like there was always something hanging over my head. But once we’ve decided to separate the two apps, immediately I could reframe my mind to concentrate on what we as a company really needed to focus on to launch a successful first product, and I realized how wrong I was. It wouldn’t have worked well for us at all! I needed to take a step back and think about our vision, what are we trying to achieve? What do the customers need?
Take a step back. Breath.
From that point on, I started looking and learning. I tried to find the terminologies for what I’ve been thinking or have been bothering me. I forgot how I googled it exactly but it was somewhere along the line of “first product feature prioritization roadmap what the fuck should I do?” (Hmm… that was a joke but now I’m intrigued about what comes up in Google.)
I think one of the first thing I wanted was to find a way to lay my ideas out and prioritise them, and one of the things I read was 3 ways to prioritize your product roadmap with a matrix. The matrixes were ok, but what I found really helpful was the final “User Story Mapping” bit, which has a link to Jeff Patton’s How You Slice It: Design your project in working layers to avoid half-baked incremental releases. It’s one type of prioritization technique that can help you and your team seem how each potential new feature fits into the customer’s experience of your product. One line in Jeff Patton’s pdf summarised much of the problem I’m facing:
“How do you choose a first bundle of features that is both high value and immediately useful?”#
Great. So I started trying to list out my feature ideas in this User Story Mapping way, but quickly found that “Wait. I’m still down at the features level. I need to go back up and empathize with our customers. What drives them? What motivates them? That’s when I remembered something I had read called “Job Stories”. A quick google brought me to 2 great articles: Meag Tessmann’s Job Stories Vs. User Stories, which then brought me to Alan Klement’s Replacing The User Story With The Job Story. Its tagline, “Too many assumptions are dangerous”, was exactly the problem I saw when I started writing out features in User Story Mapping.
This brings us to now. I’m compiling a list of moments throughout the day for parents with new born babies, 1–2 year olds, 2–3 year olds, putting them in a job story format like this:
When [a moment of frustration] + I want to [how progress is visualized] + so that [how life is better].
We’re inviting parents to join a human-centred design session next week in San Francisco and Hong Kong, I hope to gain some real insights that’ll allow me to create features that touch actual pain / joy points in parents’ daily lives.
So there. That’s how I’m Product Manager’ing. I’m super happy that this week several co-workers had told me they appreciated my balancing the need of the users Vs. the need to produce something; my showing appreciation for the team’s work; and feeling they have a better sense of what they need to do after talking to me. I’m slowly re-thinking my childhood, I thought it was pretty bad, with a meaningless, rote-learning centric schooling. But now, I think perhaps it wasn’t so bad. May be my temperament, my always being the man in the middle between conflicts, playing with friends, fighting with friends, all of that shaped me into someone who’s pretty good at this product leader role.
BTW, it seems that much of what I do requires a narrative. Writing these blog posts actually help me organise my thoughts. I quite enjoy writing them, but at the same time, I’m conscious of how well (bad) it reads. How can I continue to write these diaries, but in a more interesting way for readers? That’s another thing I’m thinking about. Thanks for reading this mess.
It’s pretty interesting to me how I sound much more confident than 9 weeks ago, before I started work. You can go back to read how at week 3, I felt much happier, and at week 5, I messed up.