Key to Product Management Success: Building Team Morale

teams_204s-600x400[1]

In a recent live stream from one of our mentors of The Product Mentor, Jenn Bornstein, lead a conversation around “Building Product Team Morale”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy

Advertisements

Start making better product decisions: A framework to go with your Agile Process

Guest Post by: Alex Hsu (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Addi Regev]

Why do I need a framework?

A research conducted by Alpha UX found that 25% of Product Manager surveyed wished for a clearer product roadmap and strategy. This was second only to increase in salary!

clip_image002

Research article

While salary increase is a complex subject with variables outside of our control, I believe that having a clear product roadmap and strategy is every Product Manager’s responsibility. Without a clear roadmap and strategy, a Product Manager won’t be able to make impactful decisions. And over time, this can mean the difference between a successful versus a failed product.

So to help you achieve this goal, I’ve laid-out a foundational framework that can be used to store and organize incoming product requests into repositories that describe your product’s strategy. Once implemented and properly maintained, this can help you obtain the goal of having a clearer roadmap and strategy, which should help make good product decisioning easier.

Lastly, to make the most out of this framework, it’s best if your organization has already implemented some variation of the Agile Methodology. If not, this can still be applied to most existing process with some tweaks.

Enough talking. Show me the money.
Themes, Epics, User Stories

To start, break down any incoming feature requests into Themes, Epics, User Stories using the following suggestions.

Themes are critical building blocks for your product’s strategy, each Theme is usually a statement describing an idea that is critical to the vision of your product. Epics are large features that together makes up a theme. Lastly, User Stories are “chewable bits” that together makes up an Epic.

To help illustrate the relationship between Themes, Epics, and User Stories and how they can be applied in practice, I’ve included an example of the hierarchy between each item and how they can be written within the context of a fictional spaceship company.

clip_image003

Example User Story:

A User Story is a description of a functionality written from the perspective from the person requesting the capability.

The User Story should be structured to include:

  1. The requester’s role
  2. The desirable outcome once request is delivered
  3. The benefit to the organization or end-user once request is delivered

For Example:

“As an Astronaut, I want an altimeter to tell me my current altitude from the surface”

For more details about writing a good User Story, refer to this article.

Each of these items are also useful when communicating your product’s strategy to various stakeholders within your organization.

Themes typically describes abstract ideas or concepts critical to your product vision. As a result, they are useful when discussing product strategy with senior management or describing your product at a higher-level without getting into details.

Epics and User Stories, on the other hand, should be concrete features or tasks that are useful when explaining and assigning work to designers or engineers. Epics are also useful when describing features to an end-user of your product or service when collecting feedback.

clip_image004

For more details about Theme, Epic, and User Story, refer to this article.

Quarterly Objectives

This document can be used to communicate quarterly objectives that you hope to achieve. Items that go into each quarter should be made up of Epics or a features you hope to achieve.

Below’s an example of how objectives can be structured:

Q1 2017

Q2 2017

Q3 2017

Rocket Booster

Navigational Computer

Spacesuit

Ions Engine

Sleeping Quarter

Detachable Landing Vehicle

Pilot Cockpit

To maximize its potential, all Items included in this list should be shared and discussed with your business stakeholders so it’s aligned with their needs. A well understood set of quarterly goals where all business stakeholders share the same understanding of the deliverables and their priority is critical for business planning and external communications.

Second, each item under Quarterly Objectives should be traceable to a Epics or Themes so they can be worked on. If done correctly, this document can be a powerful tool that motivates your design & engineering team by setting ambitious yet achievable & well-planned goals.

Third, this will be one of the most important documents that can be used when trying to make product decisions. By looking at this list, you should be able to identify valuable requests and their priority within the overall roadmap.

Lastly, always leave room for changes in scope and timeline to account for gaps in estimation or other factors that might be out of your control. Also, shift the time period according to the context of your product or organization, as an example, an early product that’s still trying to find a market might have a shorter timeline compared to a more mature product.

Milestones

Finally, you want to set achievable Milestones. Each Milestone should be a plan that contains a deadline as well as an agreed upon set of User Stories or Epics (Let’s call these scope). The scope and deadline should be understood and agreed upon by any party involved in the planning process.

To maximize their potential, tie deadlines to meaningful business events that help market your product to its intended Target Audience. Some example can include tradeshows, product summits, or client demos.

Below’s an example of how Milestones can be structured:

Milestone 1
Tradeshow
(1/15/2017)

Milestone 2
Client Demo
(12/25/2017)

Rocket Booster
Space Suit

Ions Engine
Pilot Cockpit

Try to avoid any changes in scope and timeline once agreed upon by all parties involved. Unlike the Quarterly Objectives, if done correctly, a milestones should be tied to a business event where audience should include external prospects or clients. These type of audience are typically less tolerant to changes in expectation that has been communicated to them prior.

But why did I choose this framework?

I chose this framework because of two major reasons:

  1. It can be used when communicating across any layer of management or external stakeholders
  2. Its wide-adoption across most industries and company sizes means there are various tools and resources to choose from.

As a result of its wide adoption, there are various tools and resources built around this framework each targeted to fulfill the needs of their target market, the following research data compiled by Alpha UX shows most commonly used planning tool amongst Product Managers surveyed and can be served as a directional indicator when choosing the tool to implement within your organization.

clip_image006

Research article

So… What’s next?

I wrote this article hoping that it will help Product Managers stay more organized and make better product decisions.

This is not meant to be a one-size-fits-all solution, I would strong encourage you to reflect on this framework within the context of your product and organization’s need and come up with your own evolution of this framework.

For additional readings. I recommend visiting the following sites. Each of these sites contains an array of articles that dives deeper into various subject related to the Agile process & framework.

https://www.mountaingoatsoftware.com/blog

https://www.scrumalliance.org/community

http://pragmaticmarketing.com/resources/blogs

https://tpgblog.com/

I would also like to thank Addi Regev who spent portion of her weekends providing constructive feedbacks and suggestions that helped formulate this article.

 

About Christopher Davis
alexhsu

Alex is a product manager with years of experience in B2B Digital Marketing space. In addition, Alex also has made it his goal to grow and motivate teams to build better products that delights end-user.

Outside of his profession, Alex has made it his personal mission to promote cross-cultural awareness through use of cutting-edge technology. Alex maintains a blog where he writes about product, technology, and travels.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Agile in the Real World

large[1]

In a recent live stream from one of our mentors of The Product Mentor, Addi Regev, lead a conversation around “Agile in the Real World”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy

Balancing Data and Design in Product Management

Balancing-the-Scales-Data-Driven-and-Customer-Centric-Marketing-1[1]

In a recent live stream from one of our mentors of The Product Mentor, Vasu Vadlamudi, lead a conversation around “Balancing Data and Design in Product Management”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy

Maximizing Your LinkedIn for a Successful Product Management Career

linkedin-400850_640-1487794877-9928[1]

In a recent live stream from one of our mentors of The Product Mentor, Paul Hurwitz, lead a conversation around “Maximizing LinkedIn for Product Managers”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy

How to Quickly Prioritize Your Product Backlog

Guest Post by: Christopher Davis (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Jonathan Berg]

id_1406_608[1]

As a product manager, you’ll often find yourself with a growing backlog of user stories and product defects that need grooming and scheduling. But which ones should come first, and why? A  robust ranking framework is key to answering these questions.

Sometime after beginning my work as a product manager at Bandsintown, I was introduced by my product mentor, Jonathan Berg, to a framework that allows me to confidently justify my decision-making to key company stakeholders and to align my goals and priorities to those of the broader business. Because every team’s needs may be a little different, the framework can be adapted to many situations.

With this framework, you will be able to promote more effective communication with your development team, reduce re-work, and prioritize which defects to work on, ultimately allowing your team to achieve a much faster time-to-market. Following successful implementation of this framework, you should feel that you’ve improved your operational product management skills, focused your day-to-day activities, and increased your team’s productivity.

USER STORY PRIORITIZATION

To prioritize our user stories, my team implemented a simple story ranking system adapted from Michael Lant, founder of projectyap.com. In theory, we assign both urgency and business value a separate number from one to five, then we multiply the two numbers to determine a story’s final weight. This weight is mapped on a two-vector matrix to help us visualize and prioritize the story in our upcoming roadmap.

In practice, I plug each user story’s rankings into a scorecard inside Aha!, a wonderful product roadmapping software tool my team uses in conjunction with JIRA. Before joining The Product Mentor program, I had already toyed with Aha!’s default scorecard system in an attempt to implement fibonacci sequence story sizing with my engineering team. Ultimately, I found it daunting, causing me to ignore the feature and us to return to time-based story sizing instead of point-based sizing.

Below is an example of Aha!’s default scorecard:

After my mentor introduced Lant’s system to me, I revisited Aha!’s scorecards and decided to create a custom scorecard for user story management. This is what it looked like at first:

The values for urgency relate to immediate impact, dependency of other stories, and timeliness of delivery. For example, a story with an urgency ranking of 1 might have no time constraint and very little impact, while a story with an urgency ranking of 5 might be extremely time constrained, have many dependencies, and must be completed immediately to have any meaningful impact.

The table below provides Lant’s example wording for ranking a story’s urgency:

5

Extremely time constrained.

Extreme level of dependency of other items on the completion of this task

If not completed immediately there is little or no value to doing it

4

Highly time constrained

High level of dependency of other items on the completion of this task

Important to go into the next sprint because of customer or contractual requirements

3

Moderately time constrained

Moderate dependency of other items on the completion of this task

Desirable to complete in the next one or two sprints

2

Minimally time constrained

Minimal dependency of other items on the completion of this task

Completion in the next two or three sprints is adequate

1

Not time constrained

No dependencies

Little or no impact

The numbers for business value relate to the level of competitive advantage, impact on brand/reputation and the number of customers the story is important to. A story with a business value of 1 might be important to very few customers with little impact, while a 5 might be important to every single customer and/or critical to the survival of the business.

The table below provides Lant’s example wording for ranking a story’s business value:

5

Extremely important to most or all customers

Extreme impact on brand or reputation

Critical to the success of the business

4

Important to many customers

Significant impact on brand or reputation

Significant competitive advantage

3

Important to a moderate number of customers

Moderate significant impact on brand or reputation

Moderate important competitive advantage

2

Important to only few customers

Minor impact on brand or reputation

Minor competitive advantage

1

Important to only a few or even no customers

Little or no impact on brand or reputation

Little or no competitive advantage

Now, how do you make the work actionable once you’ve assigned each story its numbers? That’s where priority comes in. Below you’ll see Lant’s original story priority matrix:

After mapping your story across the priority matrix, you need a color-coded key to help you decide when to take action. Below is Lant’s original story priority key:

After creating my original Aha scorecard, I began using this color-coded matrix and actionable color key with my own team. Due to resource constraints, I quickly realized that my boss and organization in general is a bit more comfortable with addressing 6’s, 8’s and 9’s at a later point on the roadmap than Lant suggests, so we adjusted the story priority matrix to look like this:

DEFECT PRIORITIZATION

After my team had a system in place for prioritizing user stories, we began struggling to work in defects. “Can’t we use the same framework?” I wondered, and as it turns out, we could!

Leveraging another article from Michael Lant, we created a matrix to work from that was similar to our story matrix, but with different criteria that made a little more sense when addressing a defect (also known as a bug, or whatever you want to call it).

To prioritize our defects, we changed what’s on the X and Y axis of the two-vector matrix. Instead of urgency, we use scope, and instead of business value, we use severity. For each, we still assign a number from one to five, then we multiply the two numbers to determine a story’s final weight.

I went to add a second scorecard in Aha! after settling on these criteria and I realized that the software only allows you to assign a single scorecard per product. This was a problem. My solution was to combine both defect and story prioritization into one scorecard.

View an example of the combined scorecard below:

For defects, the values for scope relate to the amount of users affected and the amount of system functionality affected. For example, a defect with an scope ranking of 1 might affect a very small set of users and/or a tiny piece of system functionality, while a defect with a scope ranking of 5 might be affecting all users of the product and/or most system functionality.

The table below provides Lant’s example wording for ranking a defect’s scope:

5

Affects most or all users and/or a very large range of system functionality

4

Affects a large set of users and/or large range of system functionality

3

Affects a moderate set of users and/or moderate range of system functionality

2

Affects a small set of users and/or a small range of system functionality

1

Affects a minimal set of users and/or a very small range of system functionality

The values for severity relate to how easy it is to get around the defect. For example, a defect with a severity ranking of 1 might only be a typo or some small cosmetic issue, while a story with a severity ranking of 5 might be corrupted or lost data, or a system that is entirely unavailable.

The table below provides Lant’s example wording for ranking a defect’s severity:

5

Data loss, data corruption or system unavailable

4

Important functionality is unavailable with no workaround

3

Important functionality is unavailable but has a reasonable workaround

2

Secondary functionality is unavailable but has a reasonable workaround

1

Cosmetic issues or some functionality unavailable but has a simple workaround

Once again, we need a color-coded matrix and associated key to help us address each priority color. Below you will find Lant’s original color matrix:

Similar to our story matrix, we adjusted the defect priority matrix colors to look like this:

And here is Lant’s decision-making key for defects:

As a result of these new ranking frameworks, my team was able to work our way through a long, seemingly never-ending list of defects that were rarely being addressed. I’m now feeling better about the quality of my product from both a defect management and a new feature prioritization perspective. Our process is much more streamlined, and I am able to quickly throw ideas and defects into unranked buckets before I properly rank and prioritize them. This way, I never lose an idea if I am too busy working on something else.

Screen_Shot_2016-04-22_at_1_39_14_AM.png

And that’s it! I’m still iterating on this process myself, so I would love to hear if you are able to apply a similar process to your own team using new methods or tools other than the ones mentioned here.

Good luck!

About Christopher Davis
ChrisDavis-headshot_8-3-2013_500x500Chris is a Product Manager at Bandsintown, Product Expert in Residence at General Assembly, and a writer and editor for music magazines including DJ Times, ClubWorld and The Music & Sound Retailer. Additionally, Chris is a life-long percussionist, DJ, and a music producer that has performed in wind symphonies, the Atlanta Falcons drumline, and various bands. He is also a graduate of The University of Georgia and is a huge college football fan. Find him on Twitter and across the internet at @chriskdavis.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Product Manager Advice: Working with Designers

senior-designer[1]

In a recent live stream from one of our mentors of The Product Mentor, Jonathan Berg, lead a conversation around “Working with Designers”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy

In Product Management, soft skills lead to hard lessons

Guest Post by: Jince Kuruvilla (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Rishi Kumar]

v2[1]

Regret, sorrow, disappointment – not all team check-ins and spec reviews end like this, but for a while, most of mine did. I mean, I was nearly a year into my first real Product Management position and I still didn’t feel like I knew what I was doing! Sure, I had spent the majority of my career as a UX Designer, and when I transitioned into a Product Manager role, I made sure to work tirelessly and develop “hard” PM skills like market analyzation, feature prioritization, a command of AGILE, etc. I knew how to build successful products and how to communicate & collaborate effectively, so why was I having such a hard time being a Product Manager?

Well, it took me a while (and a lot of long conversations with my mentor, Rishi Kumar) to realize that my brute force technique wasn’t working. In my quest to learn so many hard PM skills, I seemed to have missed the importance of learning the softer side of being a PM – building and maintaining close relationships with your team.

calculatedistance[1]It wasn’t like we actively distrusted each other – more so the fact that we rarely saw each other in person – we had a wee 4,225 mile gap between myself in Brooklyn, NY and my engineers in Poland. Don’t get me wrong, we communicated pretty frequently –  emails, Skype chats, and a few weekly video chats. Technically, we were in sync and producing great work but the problem was that the great work never aligned: I’d make great specs and document great features, but my engineers felt uncomfortable asking questions and being overly critical of the specs while I felt embarrassed to ask about technical issues, resulting in features being built that were far from the specifications.

My mentor, Rishi, took time to hear me out and help dissect my issue. If anyone could help, it was him; he also worked with a remote team in a different time zone—he could empathize and understand my situation. Rishi even went on to give a fantastic presentation about working remotely to the Product Group! In his talk, he discusses concepts like communication equality, the importance of making personal connections, and most importantly, building trust through transparency/visibility. Rishi helped me realize that in order to address these issues I was having, I needed to take a different approach to my work relationships. With his guidance (and the nuggets of wisdom that the other mentors in the program shared on the youtube presentations), I set out with a new approach to building greater trust and camaraderie within my team:

  1. I established a strict daily “standup” meeting.

    My Polish teammates and I  communicated through email and skype messages constantly, so initially, there never felt like a real need for a standup. A few weeks after starting a daily standup, however, I could see why they’re such a crucial element in Product teams – the daily standup allowed me to have face-time with my coworkers and have a chance to interact informally with each other. The daily standups, though redundant at times, helped us grow closer by formally creating space for conversations to occur and for viewpoints to be explained.

  1. I set out to share my raw, unfinished work with my teammates.

    I will admit that I have a tendency to be a perfectionist. I’m no stranger to sharing my works in progress with my fellow PM’s but sharing with developers and engineers meant being able to explain every little technical detail – I couldn’t “paint in broad strokes,” is what I had initially thought.

    Work_In_Progress[1]I experimented by having a few collaborative work-sessions with my developers over Skype – I showed them sketches and very rough concepts and ideas to help them understand my point-of-view but also to give them a chance to make suggestions and iterate together. At first, the conversations were laborious and slid very far onto the technical side of things, but we soon found our footing and were able to have both high-level “broad strokes” conversations alongside the technical/implementation questions.

    Through this process, I ended up becoming quite comfortable with the phrase “I don’t know. I’ll look into that.” I was initially afraid that showing this vulnerability would tarnish what respect they had for me, but soon found that they respected me even more for sharing my process and unfinished ideas. Not only did it give us a chance to brainstorm and ideate together, it allowed my team to see a side of our process that they hadn’t seen before.

    Soon after, my teammates would set up meetings with me to show me their own unfinished work: rough builds of features they were working on. Product demos were starting to happen nearly daily (instead of once or twice a week, previously) which led to greater transparency and greater shared ownership in our product development process..

  1. I set out to talk about anything but work .
    20151201182321-business-people-drinking-coffee-talking-networking[1]
    As pedestrian as it may sound, this was probably the biggest takeaway for me. It’s easy for me to socialize with my co-workers in my Brooklyn office since we spend so much (physical) time with each other – but my teammates in Poland don’t really get to see that “social-Jince” since most of our communication was work-related.

    To counter this, I set out with a peculiar strategy – I set up calendar invites as reminders to myself to have non-work-related conversations with my Polish counterparts – conversations to check up on their families, their hobbies, etc. As embarrassing as it sounds, the calendar invites helped tremendously in making sure I had these conversations.

    I learned so much about my coworkers and what made each of them tick. It all eventually helped me understand how best to communicate with them at work. I knew that Piotr, with his design interest, could understand when i talked about functionality in broad, visual strokes, while Michal was less interested in the visual side and wanted to know what the user goals were and the rationale for every single UI element and product decision. These learnings led to more efficient work-related communication between all of us. 

I was skeptical at first, but focusing on building these soft skills of navigating and forming camaraderie with my remote co-workers has been, without a shadow of a doubt, one of the greatest lessons I’ve ever learned in my Product Management career. The results speak for themselves: after about a month of implementing these new tactics, team morale increased tremendously and we hit our stride. Spec meetings and daily standups were no long foreboding events, but events that our team looked forward to.

I’m happy to share that our team’s friendship has evolved to become the foundation of our working relationship – our interpersonal connections have helped us successfully navigate tense product conversations and establish a wealth of empathy for each other’s’ roles and responsibilities.

The soft skills that the The Product Mentor program drove me to learn have lead to hard lessons; most of which come back to a simple idea: in order to build great products, you need to have a great team — in order to have a great team, you have to work on building trust, camaraderie and a sense of belonging. Only then will you and your team be able to produce the best possible work possible. Take it from me—I learned these soft skills the hard way!

 

About Jince Kuruvilla
JinceKuruvillaJince is a Product Manager with a background in User Experience and Design Strategy. He’s carved a career for himself working on products that inspire and empower people – everything from physical products to digital experiences. Ask him about spices, social entrepreneurship, and hip hop trivia — you’re sure to get an earful!

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Working Remotely in Product Management

blog_remote_01[1]

In a recent live stream from one of our mentors of The Product Mentor, Rishi Kumar, lead a conversation around “Working Remotely”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy

Measuring from Product to Development

asdfasdfasdfasdf-728x346[1]

In a recent live stream from one of our mentors of The Product Mentor, Bennett Morrison, lead a conversation around “Measuring Product and Development”.  We are always looking for more product mentors from all around the world.  Signup to be a Mentor Today!

View the live stream…

 

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.

Enjoy!

Jeremy Horn
The Product Guy