Take home assignments, case study, business case - they go by different names. But, this is the stage of a PM interview that candidates are often anxious. Why do companies hand over such assignments? Primarily, they want to understand your thought process and see how it is to work with you. However, there are strong opinions regarding PM assignments. Some have stated that they dislike problem statements related to the company's product. Some pretty much despise it.
I started by hating these assignments and grew to love them. Having gone through quite a few of these over the years, I wanted to share a few tips on how best to handle PM assignments.
Personally, I think this is a wonderful opportunity to flex your skills, interact with the product team, and get to know what it feels like working with them. Here are some things that helped me excel at PM assignments, after learning from mistakes,
Pick the metric that matters. Don't stuff too much into the outcome. In one of the interviews, I choose 4 metrics. I was just trying to make sure that I showcase my research and ended up documenting vanity metrics. This was not a good idea. Stick to one metric, and in some cases where you need to track direct and indirect outcomes, two metrics.
Be concise. Your research document or presentation should speak for itself. It is ok if your assignment goes to 2-3 pages, but make it worth it. Resist the temptation of adding a lot. In on of my first PM assignment, I did so much research, and cramped everything into the document. I made it look great, but it was information overload.
Ask for inputs. The very first assignment that I worked on, went very poorly. Not because I didn’t draft it well, but because I ended up interpreting the problem incorrectly. It's easy to misinterpret words, so you'd rather request the recruiter or hiring manager for some time to clarify the problem. You will be surprised to see that they will be more than happy to give you inputs. This is also a treasure trove for more ideas and context. But beware that you are requesting for someone’s time, so be well prepared to make the most of it.
Be clear about the time you need. I always prefer to work on assignments during weekends, and prefer to give the audience enough time to go through my work. Communicate in advance, the time that you may need. For the assignment itself, I noticed that less than 2 hours is too less. More than 5 hours is an overkill. Manage your time well, and don't immediately focus on aesthetics. Spend 50% time on research and notes. Then 25% in brainstorming. Remaining in compiling your research.
Set the stage. Remember that this assignment is an opportunity to flex your skills. If you get an invite with all the team members, take the opportunity to prep the audience in advance. Send in your assignment and request the team members take a look. During the presentation, introduce what this session is about (as if it was a backlog refinement session), set expectations, and state the goals.
Introduce yourself. I can’t imagine how many times I had a case study presentation with new team members, where I wished I had more time to introduce myself. Instead, I use a service like Loom to customise an intro message for the participants. You can save 5 whole minutes! That way the audience will already get to know you, and you can just add an intro slide instead of spending your valuable presentation time. This has worked wonders and has even earned the audience’s appreciation. Share this video while sending in your assignment.
Engage the audience. Always remember that the point of this presentation is to get a feeling of how it is to work with team, and vice-versa. Narrow down the scope of the session immediately. Don't spend too much time trying to set a context. Leverage the fact that you had already sent the documentation in advance. Also, don't just rant, keep the audience active. Here are some tools you can use to make the presentation interactive:
Use a polling software like Slido. The free version offers 5 polls, and it has worked great for me. Start with a contextual icebreaker. If the problem is about music, ask the audience their favourite artist. If it is about public transport, ask what challenges the audience faces.
Use a collaborative editors like Google Docs. During the presentation, there will be many opportunities to bring collate the audience's ideas. Use this opportunity and make this more a workshop than a presentation.
Use a distributed workspace like Miro. During one of the interviews, someone recommended Miro. It's an awesome product to organize product workshops. Give that a shot. This will also help you showcase your ability to work remotely, seeing that post-COVID this may be the way forward.
Summarize the presentation session. Remember there is no right or wrong way to do present a PM assignment. Even if it means that you as a PM should do more research and come back, let the team know, and don't leave them hanging. The idea of this session to help the team get a shared understanding of the problem you're working on. Does the audience have any tasks? Do they need to help with some more research? What are the tasks? What are the priorities? If you still need to do more research state so. Use the Strategy section to list the way forward.
Keep track of time. The presentation session typically lasts between 60-90 minutes. Make sure that you be wary of time. While it may be tempting to show off your research, be aware that the audience, many of whom have not met you, may have many questions to test your skills. The best thing you can do is rehearse in advance. Note down the time you want to spend in each section and practice. Leave ample time for feedback and discussion. The team knows very well you can't do a lot. Just as a good PM would, prioritize well.
If you have come this far, here's a little token of appreciation: PM assignment template. This is a template from my previous interviews. Please feel free to leave your feedback or comments to improve it.
If you or someone you know have been part of PM assignments, I'd love to hear what your experience was and hear how I can improve myself.
Over the last five years of my product management path, I have come across some interesting product management discussions. The most common questions from these conversations were,
The onus, to address these questions, lies significantly on the product manager. As a product manager, you can never work in a silo. You need to interact with internal stakeholders, engineering teams, and most importantly with the customers. In this article, I document a framework to inspire your product teams to build products.
Before that however, there is an even more important question that needs to be addressed — Why? Whether it is improving the current product line, building a new product, deciding on potential partnerships, understanding customer behaviour or proposing new products for tapping new revenue streams.
The answer to "Why?" is what helps product teams take better decisions and enables them towards success.
Understand the vision of the company. I always recommend that you start by gathering a thorough knowledge of what the company is trying to do, what the company's mission is, and what the founding team's vision is. Interview the founding team to get a high level understanding of their 8-year plan or 5-year plan. If you're part of a younger company, the 5-year or 3-year vision. As a product manager, it's in your hands to bridge the gap between business stakeholders and product strategy. You have to take action and translate a long-term plan into proactive short-team action.
During my time at Devthon, I'd inevitably end up with many partnership proposals. I never wanted to say no. But when I went back to the table to discuss partnerships with my founding team, we would always ask ourselves, "Does this partnership enable our vision?" This is where I learnt to say NO. If you're someone struggling to say no, this exercise will help you take decisions which carry the vision forward. You will find that it becomes easier to say no - now that you also have convincing reason to say no, or yes!
Key Themes. If you have succeeded in understanding the vision of the company, move further to draft the key themes the company is willing to identify itself with. What would it like the customers to associate you and your products with? Trust, Expertise, Usability, Secure, Speed, Happiness? This point might sound insignificant, but you will see how much it matters once it trickles down to roadmap or sprint process. You will start asking yourself more often than ever, "Does this feature help the customer associate us with the key themes?" "Does this blog post reflect any of the key themes?" "Does this action mirror any of the key themes?" And so on.
Areas of Focus. Wait. But, this sounds very similar to Key Themes. Read on, and you will soon realize that this is quite different. Going back to the time I was part of Devthon, we focussed strongly on our innovation process - it was our key to an efficient business model. All our efforts were focussed on driving this innovation process that we designed after two years of experience, building product teams, and leading them towards product development. As the company and product start to grow, it starts to perceive opportunities in other areas. Devthon started with its focus on the education sector. The innovation process spread like wildfire around educational institutions. New ideas have potential revenue streams that surely add value to a company. But when you have defined focus areas, you have a guideline to pause and understand the decision. Focus areas are never fixed. A company is free to amend it every 2 quarters or annually. It helps everyone to stay focussed and accountable.
Metrics. All of the above is left without purpose if success cannot be measured. How can you say that your team or product or company has succeeded? What guides actions and decision? It is a set of quantifiable points that can be measured and achieved. And, data is currently the only way for us to gauge success. It's often easy to get overwhelmed while building a product with feedback from customers, suggestions from investors, or even ideas from the team. It's hard not to lose track. It's even harder not to start measuring wrong data points - And still end up cheering false success. This framework provides a way to structure the madness it is to build products.
It is important to also understand that product teams, especially engineers, love clarity. But instead of telling them what to do, use the framework to your advantage and present them with challenges. You will be surprised at how the team comes together, takes the right decision autonomously, ships solutions that delights customers, and further derives the right metrics to constantly improve products.
Product teams don't need to be told what to build or how to build it - Inspire them by collaboratively identifying unmet needs.
Product managers don't just understand how to set a vision, collect and analyze data, they come with other skills that can only be gathered through experience. For example, if you're a product manager you will know that you can't just base data on a percentage or number it also needs a relative measure to time and more importantly qualitative. Or for that time when you think you moved a metric, but realized it had a domino-effect on another metric.