My Product Management Interviews (part 3 of 3)
The pre-interview test
This is part 3 of a 3 part series:
- Part 2: https://t.co/J6U9jqGDyV
- Part 1: https://t.co/IXLpJhdj7E
It took me a while before landing a new job and having the spare time to write this up so my apologies for the long wait. I appreciate all of the great feedback I’ve received from the first 2 posts and many readers have asked me when part 3 would come and so…it’s finally here.
A different exercise I experienced in my recent job search was the “take home exercise” prior to the first in-person interview. This typically was assigned once the phone interview went well and they want to review documentation and mockup examples when making the final decision.
The output of these exercises were not utilized during the in person interview but they were used by the company in isolation when comparing the experience/talents between final candidates.
Ntrucking
Email from hiring manager:
This task requires research and to show your capability of illustrating your thought process, user story writing, solutions and ideas.
Your preference of how to illustrate will be left up to you to convey this task but it will be judged heavily as well.
Task:
Ntrucking currently sells telematics device for carriers to install on trucks to track drivers driving habits/statuses and record vehicle health data.
As a new revenue stream we would like to enter the telematics industry to track trailers. Competitors like Spireon and others you can find currently support this feature.
1. What features should we support?
2. How would we build this feature out for a user to use this?
a. How would they access it
b. What user stories would you write
3. Anything else that should be addressed can be included as well
My approach to solve this was once again, using the my most successful approach, the OGSM (Objectives, Goals, Strategies, and Measures). However this time I decided to reverse engineer the OGSM for 2 competitors (one of them as described in the email) then define the “final” OGSM by selecting the goals and strategies that I felt most comfortable explaining my logic for. I also decided to leave out the M (measure)since the exercise did not describe the need for measurements or KPIs (if you can save time, I recommend avoiding it)
Most companies that have a solid go-to-market strategy generally provide great explanations of the problem statement and how their product helps overcome the problem.
I reversed engineered the OGS for their product based on this website: https://www.spireon.com/trailer-management/
Here is a screenshot of my OGS based on the page:
I then did the same thing for another competitor called Fleetilla based off this website: https://fleetilla.com/products/asset-trailer-tracking
As you can see I categorized and grouped the goals and strategies as much as possible to easily represent the cascading effect of the exercise O > G > S.
Here is the final output of the OGS to drive the final user stories:
I broke down the strategies and categorized them for easy user story creation. I was in a time crunch to complete this within 24 hours so I decided to write the titles of the user stories and focus on the mockups (using ninjamock) instead of writing the actual user stories in formal fashion. I personally like to use ninjamock for the intentional cartoony, LOW FIDELITY mockups. I make it clear that as a product manager I leverage the current UX team’s talents by collaborating and by no means present myself as a replacement for UX employees.
The exercise was successful and I indeed was a final candidate. Unfortunately the timing didn’t work out since my current employer made a final offer before this company would do a final commit and they wanted one more week to discuss internally who the offer should be made to.
There was another example I have of a more data driven exercise. Let me know in the comments if you would like me to fully detail that documentation and approach as well.
-Beats
