SPRINT16 - PM PORTFOLIO

MechanicQuotes

MechanicQuotes is a tool that allows car owners to quickly learn price ranges for needed repairs and maintenance, and compare prices at different auto shops.

Problem Statement  

People who are on a budget or are conscientious of price do not know if their car repair bill is fair. They need a quick, convenient way to determine if the price is fair to save money and/or stay on budget. 

Problem Background  

This problem originated from my experience at various auto shops whereI would receive wildly different quotes for the same repair. Conversations with others revealed a common theme: it was almost impossible to anticipate a car repair bill. Formal user and market research revealed that the problem was not isolated to my immediate network and that the current tools and solutions available did not adequately solve the problem.

Research Insights

User Pain Points

  • 89% of users surveyed do not have money saved for car repairs. This made unexpected repairs challenging or impossible.
  • 4 of the 6 interviewees shared feelings of helplessness or lack of control over the costs associated with repairs and a sense of urgency to get the repairs completed as quickly as possible.
  • 71% of respondents stated that they do not price compare when selecting an auto shop. The most common reason for this was lack of price transparency. 

Feedback

There were three key insights that came from the survey and user interviews. In order to keep the scope of this product hyper-focused, I identified the need for quick price comparisons as the most valuable to users. 

  • 4 of the 6 users mentioned – unprompted – that they wanted an easy way to compare local prices.
  • Auto shops do not post prices online.
  • Because quotes are only given after a diagnosis, shoppers were unlikely to take the car to another shop, even if they knew there was a cheaper option.

Landing on the Solution

Based on my target users' pain points and expressed need, I knew that the solution needed to provide some clarity on repair bills and a way for customers to compare prices. To make this a true MVP, I opted for the following features:

  • Select a repair, and see general price range for that repair
  • For the selected repair, display the 3-5 most affordable options nearby

User Flows/Mock ups

Below is an example of a high-level user text flow to explain how a user will compare quotes

User enters site > Examine list of repair options > Selects “New Brake Pads” > New page displays a price range for new brake pads in users area > Below are 3 local shops with recent prices displayed > User selects a shop to take their vehicle to.

Future Steps

User and mentor feedback indicates that this is a problem space with potential. I plan to present this to my team in the Co.Lab Bootcamp and work cross-functionally to ship this as a viable product.

Learnings

Product Manager Learnings:

Timothy Goodwin

I learned so much from working through this problem space and receiving support and feedback from my peers and mentors. Below are the top 3 takeaways:

1. Start with the problem space!

I had no idea my natural tendency was to immediately jump to the solution for a problem. Even worse, I found that in the solution space, I skipped over the “what” and jumped right into the “how.” 

Rapidly ideating through 40+ ideas revealed this shortcoming to me. I kept getting overwhelmed and thinking that my ideas had already been done before.

Ultimately, I needed to slow down and revisit the problem spaces I identified and just drill through the “What, Who, Why” exercise (linked below) to finally focus myself on the actual problem. 

I’m pleased with the problem space I decided on, so I’d say “lesson learned”!

2. BIP!

Until the Co.Lab Ideation Sprint, it had been about 10 years since my last social media post. I stayed away for personal reasons, so the idea of using social media to post about myself and my recent learnings was foreign to me.

Thanks to the encouragement of my mentors and peers, I started posting to share the ups and downs of my learning journey. It has been fun to do so and revealed that I am not a very succinct communicator. While I haven’t made much progress on that front in four weeks, it is on my short list for personal and professional growth.

3. It’s not about the artifact

In the words of my favorite author, Brandon Sanderson, “Journey before destination.”

User Interviews, PDRs, and Roadmaps are all nice, but I learned that in product, the artifact (the destination) is only as good as the problem-solving process that was employed.

Designer Learnings:

Designer Learnings:

Jo Sturdivant

  1. Adapting to an Established Team: Joining the team in week 6 of 8 was challenging, as I had to quickly adapt to existing workflows, dynamics, and goals. This mirrors real-world situations where you often integrate into teams mid-project, and flexibility is essential.
  2. Work-Blocking for Efficiency: With only two weeks to complete the project, I learned the importance of a structured work-blocking system. This approach allowed me to manage my time effectively and meet deadlines under pressure.
  3. Making Data-Driven Design Decisions: Unlike my past projects, I had to rely on research conducted by others. This was a valuable experience in using pre-existing data to guide design decisions, helping me focus on the core insights without starting from scratch.

Developer Learnings:

Developer Learnings:

Vanady Beard

&

As the back-end developer, I learned how important it is to create efficient and reliable systems that support the entire application. This experience also taught me the importance of optimising the database and ensuring the backend is scalable and easy to maintain.

Developer Learnings:

Stephen Asiedu

&

As a back-end developer, I've come to understand the importance of being familiar with various database systems and modules. This knowledge enables me to build diverse applications and maintain versatility in my work. I've also learned that the responsibility for making the right choices rests on my shoulders, guided by my best judgement.

Developer Learnings:

&

Developer Learnings:

Maurquise Williams

&

  1. Process of Creating an MVP: Developing a Minimum Viable Product (MVP) taught me how to focus on delivering core functionalities balancing between essential features and avoiding scope creep.
  2. Collaboration in a Real-World Tech Setting: This experience taught me how to collaborate efficiently in a fast-paced tech environment, keeping the team aligned and productive, even while working remotely across time zones.
  3. Sharpening Critical Thinking and Problem-Solving Skills: This experience honed my ability to think critically and solve problems efficiently. By tackling challenges and finding quick solutions, I sharpened my decision-making and troubleshooting skills in a dynamic, real-world setting.

Developer Learnings:

Jeremiah Williams

&

All in all this experience was very awesome I learned that in coding with others being transparent is key

Developers Learnings:

Justin Farley

&

I learned how important communication is when working with a team. Communication provides understanding, advice, ideas, and much more. While working with the product team, I’ve found that communication keeps everything flowing smoothly. Working with a team also showed me that every member brings something different to the table and we all have to work together in order to align and meet our end goal.

Full Team Learning