This is the 2nd part of a 3-part series called “How to Answer the Most Frequently Asked Design Questions with 40 Launch Product Manager,” where we have a Product Manager from 40 Launch, Rodhmir Labadie, that specializes in design answer questions that are common in design-focused Product Manager interviews. The first part of this series can be accessed here.
Product Gym: What is a burndown chart?
Rodhmir Labadie: It is a way for you to get a sense of the capacity the team is able to work against. It takes all of the story points accumulated on one chart so you can organize workflow and see what the constraints are. The burndown chart, over a period of time, shows how every member of the team should be chipping away at these story points. Once at the end of the cycle, you should see a chart that shows the number of points that have actually been addressed within that particular time frame. It is giving you a sense of the capacity a team has and the rate at which they are solving the stories on that spread.
Product Gym: What made the iPod successful enough to beat MP3 players and Discmans?
Rodhmir Labadie: One of the main reasons was timing. The iPod gave consumers an experience they were not used to, even though there were already MP3 players that were already out there. They were very effective at solving the problem of getting music onto a portable device competitive to CD quality. Users would eventually become acclimated to the idea of not walking around with a Discman. What the iPod did really well was taking that experience and making it much better.
One of the earlier iPods had a spinning click-wheel with a dial. That simple design of a one-button interface really resonated with users. The on-boarding process was easy, and they were able to get quite a bit of content onto the iPods as well. Apple did a really good job of presenting the iPod as a game changer.
I always remember this talk by Simon Sinek, where he talks about three concentric circles. In the middle, he labels “why,” the next ring “if what,” and the outermost ring “how.” This portrayal showed Apple’s position on Product Management, in which Apple first focused on the emotional pull, or the “why.” They took products that are clunky or hard to use and made them easy to use. The dial served as the “what,” or solution in that case. This process of product development based on focusing on putting everything in front of a new consumer base has been really effective.
It was a combination of genius, timing, the positioning of the product itself, and beating competitors to the solution that lead to the iPod’s success.
Product Gym: Tell us about a great product that you encountered recently, and why you like it.
Rodhmir Labadie: A product I encountered recently that I liked is called Swarm by Foursquare. Swarm is a geolocation-based app that allows you to passively check-in to different locations you may have visited. Wherever you go over time, Swarm puts everything into a really easy-to-read timeline. It puts these events into an interstitial stage, and from there you can choose whether or not to show part or their entire timeline to their friends. This comes in handy for me when I have to remember where I travel throughout a period of time so I could add to a backlog list of places I have been to.
There is an opportunity to add some machine-learning to the product where it can preemptively know where I might be going or be able to decipher my future behavior. At the moment those parts of the product are not the strongest, but, as a whole, I still find it to be one of the better products I have seen in a long time.
Product Gym: How would you implement a product to get app recommendations?
Rodhmir Labadie: It depends on what kind of recommendations we are looking for. For the sake of simplicity, let’s talk about movie recommendations.
A lot of movie products provide movie recommendations. You start with, “What is the movie itself? What year was it made? Is this movie in a particular genre? What are other genres?” There is some metadata around creating the structure of that movie itself.
Phase 1 would be to get an understanding of the types of recommendations and products we are going to produce against each other. The next phase would be to identify what these recommendations exactly are. Do you want a straight one-to-one scale where it is either one star or five stars?
It does not matter if you have 10 or 100 users to change the weight of those recommendations since the number of users is linear and does not provide for a lot of value.
Typically when customers are looking at products and something has two ratings with 5 stars and another has 2,000 ratings and 4.8 stars, people are more likely to choose the latter just due to the greater numbers. How do you measure that? By threshold of people? By weighing out each score individually? There are tons of approaches.
Once you identify what that algorithm is and identify what the solution or product is which you are going to associate these to, it will be about how you pick that solution and drive what type of software.
One of the things I have always been a fan of is creating APIs that will solve these problems in individual trumps. What am I going to use from that information to drive, and how do I pull that information into the solution that I want holistically?
That brings us to the next part, which is figuring out how to integrate that process as part of your implementation strategy. Each of those pieces becomes the baseline story that you will solve. How do I identify what we are trying to recommend? How do we go about implementing that recommendation?
We could take it a little further and talk about how to execute that instep. How large is this implementation? How long is it actually going to take to implement this solution? How does this align with our business goals?
For example, because our product offers so many different types of things for our users, our recommendations would need to be able to address all of these needs.
How do we take that and talk to the team to try and design something that meets the needs and expectations of how we are implementing this solution? What are some things we need and do not need? Once you flush all this out, it is time to start discussing sizing, which goes back to our burndown charts. It is getting the appropriate metadata and figuring out the algorithm that allows the recommendations to be more effective.
In a brown field, we have to ensure that this works within the environment that we are building. In a green field, we are starting from scratch and need to make sure we are accountable for the things we have planned for the future. We want to make one part to solve a specific problem, but the other to be more open-ended. The burndown chart will give you insights into how these problems are solved.
Then I can speak to my stakeholders about these insights and discuss scheduling for implementing these different strategies. By the middle of the first week, I can actually say whether or not we are on target and keep my stakeholders aware while creating transparency within the organization. This is also building credibility with yourself.
If a snag occurs, you, rather than waiting, could actually have made that adjustment week earlier. If you are running really behind schedule, this is an opportunity for you to really simplify the problem.
Product Gym: What is the advantage of using user story points as opposed to hours?
Rodhmir Labadie: Story points are about complexity, while hours are about time. The question, “How long is this going to take you?” is not an appropriate question in the case of solving a problem that is unclear, and it also does not set anyone up for success. You want to provide the creativity to not bind people into viewing problems as a function of time. Rather, you want them to just focus on how to solve the problem.
Let’s say that a process assigned to someone was supposed to take 9 hours, but it only took 4 hours. Now that person can use the remaining 5 hours to run a few tests, perfect it, etc. Some people may view this as a good thing. The problem, however, is that nothing is perfect until everything has come together.
It is important to have other team members there to contribute. You want everyone to work at a point where they can pass the book onto the next person. You need to look at how complex the issue is from each vantage point. By understanding how complicated it is, you can infer the amount of time it takes to complete. By doing this, you are not binding anyone to a time constraint. These different measures are always learning opportunities as well as measures of accountability.
A project manager may be very interested in time, but from a product standpoint, the user stories are really good for estimating how complicated a task really is. For example, a senior engineer can analyze the situation, see which parts are complicated and estimate the amount of progress to be made in a certain time. You could then rate them based on how difficult they are. These are how user stories create a great opportunity to talk about complexity.
Product Gym: What UX Design and Prototyping tools do you like?
Rodhmir Labadie: Some tools I like are Sketch, Envision, and Balsamic. These are all tools to eventually get the end-goal done. I think the best tools are the ones that allow you to get your ideas from your head onto a shareable document as quickly as possible. Therefore, I am also a fan of paper, pencil, whiteboards, and markers. It is really about communicating your ideas in a way that provides context into how you want to solve problems. Aside from prototyping, part of UX design is research into why they are making what they are making. SurveyMonkey is really helpful for backing up ideas with both qualitative and quantitative data. The principal is great for showing interaction types, so maybe before you get into clickable prototypes, you can create example interactions that your engineering team can understand. You can also see what feedback for those interactions may look like. They all play a role in transitioning your product from low fidelity into high fidelity.
About Rodhmir Labadie:
Rodhmir Labadie is a Product Manager at 40 Launch. Before 40 Launch, he was a former Product Manager at KPMG US. Prior to that, he worked for TheaterMania where he started as a Product Designer and then became a Product Manager. He got his Bachelor’s of Science at Sacred Heart University. He has a background in technology, development, marketing, and design, and has experience working in the energy, finance, logistics, and consumer branding industries. Rodhmir has successfully launched over 30 new products, websites, campaigns, and marketing strategies.