On LinkedIn, I began a Reasons To Hire Me series on what value I could bring to an organization with its product teams. Figured the best way to store all those reasons within a one-stop shop would be here on GitHub.
You can also check out my Second Brain of Product Thinking where I keep a collection of my daily learnings.
- Reasons to hire me - I take initiative
- Reasons to hire me - Strategic Discovery
- Reasons to hire me - Product Roadmapping
- Reasons to hire me - Product Planning Tools
- Reasons to hire me - Prioritization
- Reasons to hire me - Collaboration
- Reasons to hire me - SQL
- Reasons to hire me - Continuous Learning
- Reasons to hire me - Product Development
- Reasons to hire me - User Interviews
- Reasons to hire me - Market Research
- Reasons to hire me - Communication
- Reasons to hire me - Empathy
- Reasons to hire me - Hard Worker
Before I go into the details I was recently inspired by Felipe Vogel’s article on his job search journey.
He gave a few pieces of advice on how to navigate these uncertain times in the job market that I think are beneficial for any individual who's been on a quest looking for their next dream role, including me.
So I've decided to take the initiative here to be more active on LinkedIn, to post consistently, and to showcase my competencies.
I believe by taking initiative, you go down a path of change. And in any company, in any workplace, there's always going to be change. The amount of change varies it can be little that it does nothing to affect you. Perhaps it could even be so significant it changes your Product Roadmap or even Sprint Backlog. So one must always take the initiative to be agile and adaptable to the changes that will surround the company and your position.
We can look back and prefer things the old way (even if they are legitimate reasons) or we keep moving forward to a successful Product Launch.
User discovery and customer research tends to be pretty biased.
As PdMs we tend go to users and ask them questions regarding a specific problem that we’re trying to validate. We have a list questions that we ask knowing full well they’re going to reinforce what you think is wrong with the product.
Personally, I have been a victim of that type of product thinking and that's the wrong approach.
When approaching users, whether if you’re interviewing them live or sending a survey. You should send them a stack of problems that your users have been facing. Then you ask them to rank those problems on top of each other.
For example, if you sent over 10 problems, ask them which problem should be #1 (highest priority issue) and which problem should be #10 (least priority issue). Whichever problem is number one, congratulations, you have now discovered your problem/idea to validate.
Shreyas Doshi was the originator of this framework and I can honestly say once I adopted this into Product Discovery over the last couple of years it became a huge game changer.
Product roadmapping is essential to understand what product/features will be worked on and when they will be released. Three different audiences can benefit from product roadmapping.
-
The product/devs/design teams are an obvious one. Depending on the maturity level of your organization, there will usually be more than one product team. A roadmap for different product teams can clarify and allow visibility of what the different teams are working on and when the planned launches are determined to be, preventing conflicting dates.
-
The entire company. I find that making the product roadmap visible to all employees boosts morale. What attracts employees to companies is believing in the mission. Sometimes employees especially on the IC side tend to get too caught up in the details that they forget the big picture. Allowing them to see the big picture reminds them of what they’re working towards.
-
The shareholders, investors, and board of directors. This group tends to think about the future of the company, with good reason, more than any other audience type. They only need to see a high level to know in what direction the business and product are heading towards. From something as simple as quarterly milestones to even a five-year plan.
Honestly - there are plenty of groups that can benefit from product roadmaps but that’s a piece that could be a whole article. Roadmunk has a great series of chapters diving into those groups/details.
I've used different product planning tools such as ClickUp, Trello, Jira, Asana, Monday, and even Google Sheets.
I have to say my top favorite two are ClickUp and Jira. I'm open to whichever tool.
What I like about ClickUp is how user-friendly it is, which allows the least tech savy person to use it, create tasks, and even update their task status.
Where as Jira has a complex versatility to it in that you can even use it for product discovery. Along with creating a beautiful timeline that displays the epics, stories, tasks, and subtasks for it's tracking progress.
-
ClickUp is more suitable for stakeholders who would prefer a more friendly UX and work on a prioritization framework of effort and value (RICE).
-
Jira was mainly designed to support an Agile project management environment along with a more customizable workflow.
I recommend both - the perfect tool depends on what your PM methodology is.
Knowing how to prioritize a product roadmap is key to a successful launch. Personally, I use the Action Priority Framework for prioritization.
- Quick wins (high impact, low effort)
- Major projects (high impact, high effort)
- Fill-ins (low impact, low effort)
- Thankless tasks (low impact, high effort
High impact/low effort should always go first to finish feature requirements immediately. Whereas the high impact/high effort become major milestones of future launches.
Low impact/low effort is a value that can always be revisited at another time. Low impact/high effort should immediately be deprioritized. Perhaps a new product discovery should come out of it.
Using this model is essential to recognize where the focus should be.
In product development, collaboration isn't just part of the job. It's the heartbeat of innovation. In tech, effective collaboration relies on syncing diverse teams. It also depends on aligning them with one vision. Creating a place where ideas can be shared is the goal. Diverse views are valued. This leads to more creative and strong products.
For successful collaboration, communication is key. Clear, consistent, and open communication ensures everyone is on the same page. This includes developers, designers, and more. Tools like Jira or ClickUp can enhance this process. They provide platforms where tasks are transparent and progress is trackable in real time.
Moreover, empathy plays a critical role. Understanding the challenges and workflows of different team members can create a friendlier atmosphere. It's about respecting each role's contributions. It's about ensuring that every voice is heard. This speeds up development. It also builds a team culture. The culture is based on mutual respect and shared goals.
As a Product Manager, fostering teamwork means being a conductor. You guide each section of the orchestra to play in harmony. You drive the team towards excellence. And, you make sure the final product fits its intended audience.
Making data-informed decisions has helped me out as a PM on the next steps. Real-world examples such as.
Generating an impact list.
Pulling data on what features worked out with certain groups of users.
Understanding human behavior with a product without having to rely on qualitative feedback.
Producing almost instant product/business metrics and visualizing those data points via Tableau or Excel.
Even used for troubleshooting and quality assurance.
All of this has helped me understand the backend systems of a product more. Thus allowing me to have actual evidence of what's working and not working when conversing with devs. Bringing it back to a reprioritization of what needs to be focused on.
Learning doesn’t end when you’ve finished your bachelor's, master's, or doctorate. It’s an evergrowing tree that we must water every day to allow for growth.
It’s easy to get stagnant and believe once we’ve reached a certain point in our life that we’ve learned all the skills we need to know. And while that’s true to a fault, we do put years of education to arrive at a certain point in our lives. We start to fall back when we’ve given up on continuous learning. Which then causes the skills we’ve acquired to go obsolete and out of touch eventually. Learning and education shouldn’t be that way.
I like to take courses (certified or uncertified), subscribe to newsletters, listen to podcasts, and sign up for programs.
The above means nothing if you’re not taking notes on your learnings just like you would in school. We like to be optimistic bias and say we'll remember it in our head... we won't. Before we can implement these new ideas they must be written down first. This led to my “Today I Learned” series, you never know when your personal learning can be helpful to the public.
The thing about me is that I’ll always be one to admit what I don’t know. Be it a specific product or industry and that’s fine because I don’t need to be an expert on that right away.
What I do consider myself to be an expert right from the get-go is the development process, all the other learnings come after that. And the process I follow and implement is what follows
- The Why? - what’s the main question of why this product is being built?
- Gather Inspiration - identifying competitors and addressing what they’re doing.
- Brainstorming - sticky note with ideas on a board time.
- Creating the MVP - work with the devs and designers to ideate a robust product.
- Testing - having an invite-only group to test and learn your product.
- Shipping - with the product launch also comes the GTM strategies that need to take place to allow you to tell your story.
The above of course is a very minuscule way of a deeper method. A variation of IDEOs design thinking process.
One of my favorite things about being in the product is the development process. It's about being in a room with like-minded people from different products focused on creating something that's just an idea to a fully-fledged product.
I do have to say, in this remote world, that is probably the one thing that cannot be replicated as via Zoom, Miro. The actual brainstorming collaboration just cannot be replaced. Exploring what other similar products are there, identifying what our users need from interacting with this product, and what can we do to enhance that user experience vs the competition.
I'm a big advocate that in the beginning there are no bad ideas. In fact, they can be really far-fetched. Because at the end of the day, the MVP is constantly going to be ideated and changed until we finally have a ship to launch.
Innovation execution is key in a product development process.
Back when I was in college booking appointments to conduct research interviews for my thesis project. I realized... I have no clue how to conduct these types of interviews at all sure. I was directed to this video by my professor at the time which presented a good structure to follow in conducting research interviews. One that I didn't know I would use to this day as part of my job.
- Knowledgeable: Coming in as an interviewer prepared and familiar with the topic.
- Structured Approach: Starting off the interview with a clear explanation of its purpose and end it by allowing the interviewee to ask questions or add comments.
- Clarity in Questions: Questions should be simple, short, and to the point - no jargon needed
- Gentle Manner: I allow interviewees to complete their thoughts without rushing or interrupting, and the interviewer should tolerate pauses.
- Sensitive and Empathetic: I listen attentively and empathizing with the interviewee is crucial.
- Open and Flexible: Respond to the interviewee’s concerns and adjusts to the questions that are being asked by them in regards to the interview.
- Steering the Conversation: Organize the questions effectively to gather the necessary information.
- Critical Perspective: Be prepared to challenge inconsistencies or ambiguities in the interviewee's responses.
- Memory Utilization: As the interviewer, I need to recall previously mentioned details to connect them with current responses and avoid redundancy.
- Interpretation Skills: Clarify and extend the meanings of the interviewee's statements, sometimes summarizing them to ensure understanding.
It's important that I manage the flow of the conversation without dominating it. Along with ensuring that the interviewee understands the research's purpose and assure them confidentiality.
Idea Scale defines Market Research as
systematic collection, analysis, and interpretation of data about a specific market, industry, or consumer segment. It involves studying customers, competitors, and market dynamics to identify opportunities, mitigate risks, and make informed business decisions.
My approach focuses on identifying competitors by understanding the market, customer preferences, and leveraging various analytical tools and techniques.
Once I've done that I try to sign-up for a competitor's product if possible. From there I record my interaction with the product all the way from the landing page, choosing a free trial, registering, onboarding, and finally testing out the product. This process usually takes anywhere from 30 minutes to an hour, sometimes more. This experience allows me to understand the market and consumer behavior by seeing behind the scenes of what our competitors are perhaps doing better than us or possibly there's a gap they're not leveraging that allows us to get ahead of them. I record my experience because I know I won't be able to capture everything in my notes and it allows others from the product team to see my experience and how I as a USER interacted/behaved with the product.
The best way to discover who your competitors are besides searching on Google, is searching on LinkedIn. Just pretend like you're searching for a job LinkedIn such as "Product Manager" filter by your "industry" in the past week and just like that you'll discover existing and emerging competitors.
Aside from doing the above I analyze their pricing plan, customer reviews, social media presence, and customer journey for the future if they have it online (sometimes they do).
50% of the job in being a product manager is communication.
My philosophy and advice that I always give people is to over-communicate. Your manager, teammate, and stakeholder will not be mad at you for communicating too much. That being said - there is a balance and you have to learn specific people's communication style. Over-communication is good but if people aren't digesting the information you're giving, then you're current approach is clearly not working. And at the end of the day what matters the most is for folks to read your message in a clean and concise way.
Sometimes it does take a while to learn people's methods of communicating.
Personally I just transparently ask people who I will be working closely with what their preferred method of communication is. That can sometimes be email, zoom (meets, teams), slack (skype), text, or even a phone call.
In async communication, I've learned the quantity of information and the way it's presented matters just as much as the preferred method of communicating. Leadership in my experience always seem to prefer a deep dive on a status update for the product development process, with a summary attached before the deep dive. Whereas engineers and designers like a clean/concise message. The presentation also matters people can perhaps prefer bullet points, numerical points, or paragraphs.
Even with all this - I still like to keep all relevant stakeholders in some form of a group chat and have a document in there tracking updates daily.
My favorite quote.
Conway’s Law (coined by famed computer scientist Melvin Conway in 1967) expresses that the way an organization is structured, and how its teams communicate, will impact the way it develops technology and systems.
Couldn't be further from the truth.
Empathy is a key strength of my professional approach, enabling me to build strong, meaningful connections with colleagues, clients, and users. Understanding and sharing the feelings of others is not just a personal trait but a strategic advantage in any workplace. By understanding and sharing the feelings of others, I create a space where team members feel valued and heard. This without a doubt leads to higher morale, high morale leads to increased productivity, and a culture of mutual respect.
In user research and customer interactions, empathy allow me to truly understand their needs and pain points. This deep understanding translates into products and services that resonate with users, enhancing their experience and satisfaction. I always strive to see problems from the users' perspective, ensuring solutions are not only innovative but also user-centric.
Empathy also plays a critical role in conflict resolution and effective communication. By recognizing and addressing the concerns of others, I can navigate challenging situations with tact and diplomacy. This ensures that all voices are considered in decision-making processes, leading to more inclusive and well-rounded outcomes.
In the past, usually after a product launch. An announcement email goes out to the company informing them of the launch. Along with the email I like to include mentions of all the unsung heroes in the product development process such as devs, design, marketing, and product.
This goes without saying, but I do consider myself to be a hard worker.
I suppose when you're the son of a Chef, you do get the mindset of a hard work ethic instilled into your mind at a young age. Even more so when I was in high school I worked in a kitchen. I had to learn really fast to be a hard worker. Especially during lunch hours, nobody wants to be known as the lazy person who's holding everyone back and causing orders to be delayed. A sentiment that I feel to this day - I don't want to be the individual who is responsible for being unable to ship a product.
One of the best pieces of advice I got when I was about to start my professional career right out of college was from a mentor of mine who told me, "to do the work".
I was a little bit confused by that because to me it was a no-brainer that of course, you have to do the work. He reaffirmed that even though it's simple advice, most people will always try to do the least amount.
Which is by firsthand experience very true. And it's not that people want to do the least amount for the most efficient results either. It's that they settle for the least amount of outcome that is produced from their least amount of work. That's not me.
I can't settle for less - I take pride in my work and at the end of the day I want to make sure that I give it my all. Regardless of the outcome, I want to be able to say that at least worked hard for it.
So for me, it's incredibly easy do to the work. I know what it's like to work a fairly physical job in a hot, sweaty, and high-stress environment. In the corporate world, I get to do a job that I love (product management of course), from the comfort of my chair and thanks to the digital age that we live in from the comfort of my own home. When there are days that I feel like complaining or being negative - I simply think back on my first job in the kitchen. When those memories come flushing back it reminds me how of privileged I am to be where I'm at in life and that the work I do now is easy. All I have to do is start and get it done.
Don't get me wrong, while I consider myself to be a hard worker, I don't want to push myself to the point of burnout/exhaustion.
Yet when shit hits the fan and you need all hands on deck, you can best believe I'm one of the people who are all in.