The Product Guy | Everything product management.

.+Add.Feed Info1000FOLLOWERS

The Product Guy was set up by an award-winning product manager, Jeremy Horn. He has backgrounds in both starting successful start-ups and working for larger organizations as a product manager. Jeremy brings his hefty experience to light in this blog and allows you to read about experiences first hand. Jeremy knows what he’s talking about and he’s willing to share his knowledge with you.

If you are a great product person looking for a great product job, or vice versa, check out our job board. Thousands of employers across all areas of product, from management to design, from digital to physical, are looking to fill positions from our community.

Each week we highlight some of the recently posted openings. Check out this week’s newest, below…

Product management requires product strategy. What are your customers’ needs? How do you best solve for these needs? How do you get your team and organization to effectively solve for these needs together. These are all key questions addressed as part of product strategy.

Having no formal product management training, I found myself inheriting three products areas in the span of six months as my company continued to reorganize. I then learned that I would need to re-launch two of the products as well as hit aggressive revenue targets in one year. How was I to best achieve these organizational mandates? Initially, I thought I needed to simply focus on development processes as the product and technical teams were highly tenured and still in waterfall. To my surprise, the key need across my multiple products was to identify and drive the product strategy.

Below were what I brought to the products and how I was able to drive for quick results.

Focus on core customers and their needs – It sounds so simple and trite but I learned that customers and their needs can be quickly forgotten or deferred as operational activities, organizational changes, cross-functional agendas and other distractions arise on a day-to-day basis. By clearly articulating the customer and their needs as well as how the product solves these needs (and preferably better than anything else in the market), the product team can keep itself and its partner teams focused. For us, the first step was to engage the end users to learn about their day to day activities and pain points. We then continued to meet with our customers and users for feedback on an ongoing basis and as part of our design sprints. Because my products are in categories that aren’t particularly differentiated, this engagement alone also sets my products and brand apart from the competition.

Expand Value Drivers – With a focus on technical solutions, particularly in digital products, it is easy to forget that there are often other value drivers for a customer. Pricing, partnerships, compatibility with other systems, and servicing are just a few value drivers that should be considered, particularly if they are easier to implement for a customer relative to what is available in the market. One of the value enhancements that we quickly identified were synergies with other products and channels for cross marketing opportunities. An example, if a client decided that it wanted third party data in one of our reporting products; we also implemented a way for the client to get that data visualized in my product, all in one set up process and for minimal fees.

Prioritize ruthlessly – Product management activities are extensive – from understanding customers to communications with various teams to partnering on execution. Given the demands and constraints, which at minimum includes time, there needs to be ruthless prioritization for what matters most and what will bring value to the client. This helps to ensure value in the product. We started by focusing on getting the products – with the personas and basic use cases – right. For any release and go-to-market activities, we leveraged the activities of other product teams, by synchronizing our release dates. This also allowed us to minimize our pilot activities and, in turn, will create more buzz with the ultimate launch.

Leverage best practices from and partner with other teams – Product strategy can apply not only to what and when to fulfill a customer’s needs but how to best get it done. The fact is that Product cannot deliver alone and the best way to address the customer’s needs is to ensure that all teams are in sync and that the teams do it together. By continuously evaluating and improving processes together, teams can ensure collaboration and partnership in creating and delivering superior products. As an organization, mine was use to outsourcing development to various dev shops. With one of my products, we decided to use a consulting company that would not only extend our product, design, and technical teams but coach us in the current agile development processes. This allowed us to achieve two goals with one initiative – better improve our development processes and deliver a new product.

A lot of focus has been placed on new technical processes and approaches. To ensure that best-in-class products are delivered for customers’ needs, product strategy must be core to all activities.

About Marissa Fong

Marissa Fong is a product manager based in New York City. She is a collaborative, results-oriented, and experienced product manager, with a strong track record of launching and scaling products. She is currently leading a team of 5 product managers in managing a portfolio of products, which includes a B2B web app, web channel, and platform.

More About The Product Mentor

The 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

Excerpts from our conversation with The Best Product Person of 2017, Melissa Perri.

In the Now

> What do you like most about being a product manager?

My favorite part of being a Product Manager is seeing a satisfied customer. When I can deliver a product that really means something to someone, and see how it impacts their life, that’s pretty special. The outcome of what we create is always what motivates me.

Watch now and see why she is counted amongst the ranks of the best in product management.

Best Thing about being a Product Manager - YouTube

More to Come

The Best Product Person (TBPP) is the leading international award honoring excellence in Product Management. Established in 2010, TBPP is awarded annually in association with The Product Guy and The Product Group.

The Best Product Person (TBPP) is the leading international award honoring excellence in Product Management. Established in 2010, TBPP is awarded annually in association with The Product Guy (http://tpgblog.com) and The Product Group (http://meetup.com/theproductgroup).

TBPP Recognizes 1 person each year, invites them to speak and share their knowledge and experience with the larger product community. The nominations can be submitted by anyone. Over the course of the year, the various nominees are interviewed and the finalists narrowed down to: The Best Product Person of the year . The finalists are interviewed and evaluated for excellence in Product along the following lines… Becoming a Product Person, Your Product, Advice to Product People, and Future & Trends.

TBPP is both (1) the way the Product community gets together to recognize excellence amongst our ranks as well as (2) provide, to a large audience, insights into that excellence in a manner we can all learn from and leverage in our own Product journeys.

The Product Group is an opportunity for Product Managers, etc. to come together to meet, interact, and network. It’s an awesome way to meet fellow Product People in a laid-back, conversational environment within which sharing and learning can flourish and complement the knowledge base for all on a peer-to-peer basis. The NYC chapter of The Product Group meets the first Thursday of each month. If you are interested in a establishing chapter near you, please contact The Product Guy or The Product Group for more information. (https://tpgblog.com/theproductgroup/ )

So, I’ll start with this: a little while ago, I was having a difficult video call with my tech lead. We had just hired a new VP of Product who was radically (and rapidly) changing our product development process, and our engineers – based remotely, in Argentina – were struggling to keep up.

“To be honest, I think we’re still just figuring things out over here,” I told him. I didn’t speak lightly; I knew our engineers were struggling with the changes and that what they needed most of all was definite information, and fast.

But rather than pressing for answers, my tech lead simply sat back in his chair and shrugged. “Ah, well,” he said, “at least it’s better now than it was before.”

“Better?” I furrow my brow incredulously. “What do you mean?” I asked.

“Well, before, product knew what was going on and engineering didn’t.” Leaning forward again, he said, tongue-in-cheek, “Now neither of us know.”

I start with this story for two reasons. First, it illustrates (admittedly – but I’d argue necessarily – in a harsh light) the difficulty of communicating effectively with an entirely remote engineering team. Second, and more important, it shows the demotivation and binary thinking that can result from bad or nonexistent communication. In this particular instance, of course, there were some other factors at play – but even so, it seemed necessary to me to ask: How has this happened? And what can I do about it?

Over the past decade, working with remote engineers (at least in some capacity) has become increasingly likely. Due to the heavy globalization of the tech sector – a challenge at once propagated and mitigated by improvements in videoconferencing and file sharing software – product management can now involve setting priorities for developers across the world as well as around the office. Even though it’s documented as a difficult place to work, companies hire remote developers (and even entire teams) because it’s more cost-effective.

But physical distance is complicated by other distances, as well. In my last product position, my team consisted of two engineers (one of them my tech lead) on the West Coast, three engineers in New York (and one in D.C.), and one engineer in Iceland. With Iceland five hours ahead of, and the West Coast three hours behind, New York, we had as a team only 2-3 hours a day in which we were all working. In my current position, my developers aren’t far removed in terms of time, but they’re over 5,000 miles away, live in a vastly different socio-economic culture, and speak an entirely different language.

So, what can one do? Here are the three most critical things I’ve learned about working with a remote engineering team.

Regular visits are crucial

All of the companies I’ve worked for that have employed remote engineers have fortunately also believed in scheduling regular visits to or from the central office. It seems obvious (because it should be), but there is nothing that can replace face-to-face interaction. If your company brings remote workers to you, great — but it’s even better if you can arrange a trip to the remote office. This is because understanding how one of your remote engineers works and what he or she is like as a person is not the same thing as understanding the culture within they’re working. Argentinians, for example, are far more laid-back and familial in their office culture: their after work celebrations are often much more low key, and it’s common for friends and children to attend as well. People are in general more friendly with each other, whereas in New York we’re nice but also more business-focused and to-the-point. Without understanding this culture and how your business fits into it, you won’t be able to build the best team possible. Your team has to work with the culture, not against it.

Regardless of whether or not you can visit the remote office, it’s essential that, when your remote engineers visit, you use that opportunity to get to know them socially and to introduce them to different parts of the organization they might not see. Engineers are great problem-solvers, and chances are the engineers on your team are smart, dedicated people – as a product manager it’s your job to make sure they have the right information, and the best way to do that is to get them into as many in person, non-tech meetings as you can:

Contact your account management team and see if your engineer can sit in on a client call or, even better, go on a client visit.

Ask if they can sit in on a sales call so that they understand how they product is being sold.

Set up a meeting for them and your product marketing manager, so they can understand how what they’re building is being represented and packaged to the public.

Let them sit with a support represented so that they understand the hard work that’s done to triage bugs before they’re sent to engineering.

Any non-tech information or experiences you can get to your engineer while he or she is visiting is crucial for making sure he or she has the right information with which to make decisions while remote.

Team communication isn’t enough

You should already being having frequent meetings with your team, even outside of the traditional agile meetings like backlog grooming and retro – but that’s not enough to ensure that your priorities are getting across, especially if you’re working primarily though your tech lead.

One of the most important process changes I’ve put in place over the past few months is that I must meet individually with each engineer on my team at least once a month. We must meet not because I am their boss (they report to Engineering, not me), but because otherwise there is a high chance both that information will get lost and that the good ideas or talents of some individuals will go unrecognized from a business perspective. Doing these 1-1s is a small time commitment on my part (it requires between 1-2 hours each week), but the benefits far outweigh the costs.

Understanding engineers’ motivations and talents can help you flesh out work more effectively

Without a doubt one of the biggest mistakes a new product manager can make is to view all engineers as equally capable and interested in a certain type of project. Every engineer is different, and if (like me) you’re fortunate, the engineers on your team will have a wide range of motivations and interests. Some devs love open-ended research, others hate it; similarly, some devs are interested in technical projects whereas others want to work on more client-facing projects. While it would be a mistake to prioritize work based on what your engineers want to do, or to only assign certain types of work to engineers who enjoy working on those projects, knowing motivations and talents can help you to build a more engaged, collaborative team.

Understanding engineers as people, and allowing them to understand you as a person, can help you build a strong working relationship

Just as it’s not enough to hold only team meetings, it’s not enough to talk just about work during 1-1s. Especially with remote relationships, it can become dangerously easy to reach out to someone only when you need something from them. Regular 1-1s create a space to learn about who your engineers are as people, and what their lives are like. Not that you have to get too personal — I’ve found it’s useful to ask about the small things (where they may be going on vacation) as well as the big things (are they happy in their current role? What would they like to be doing in a few years?). Although it may seem small, it goes a long way to understand whether someone on your team views their job as just a job or as a role they really love, whether they see themselves climbing the ladder over their career or feel that management is the last thing they’d like to do.

Getting the relationship right is more important than getting the product details right

I think this is probably the more controversial of the three things I’ve learned recently about remote communication — and, to be clear, I’m not saying details aren’t important or that having the right communication tools doesn’t matter. But I say this because I’ve worked in product organizations that view their devs purely as resources and believe that sending extremely detailed product specifications to remote engineering teams is the best way to work. I’ve even seen this in interviews, when I’ve asked candidates how they adjust their product management style to work with a remote team; they emphasize being more detailed and precise, more calculated.

While being detailed is important, however, it shouldn’t come at the cost of your engineers’ autonomy or happiness. It is much better to focus on building a working relationship with your engineers in which everyone feels comfortable asking questions if they need help. Again, your engineers are great problem solvers — it’s far more important for you to make sure they have the right information about the problem and its context rather than to make sure they know exactly how they should build a solution. Focus on the working relationship you’re building with your team, and trust/guide them in building a great product, not only as workers but people — just make sure they’re attacking the right problem.

About Stef OrzechStef Orzech is a people-focused product manager who cares about building strong teams as well as great products. Originally interested in law, he decided to go into tech after learning how to code (by necessity) at a Hackathon. In his spare time, he enjoys rowing and cooking up a storm.

More About The Product MentorThe 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

If you are a great product person looking for a great product job, or vice versa, check out our job board. Thousands of employers across all areas of product, from management to design, from digital to physical, are looking to fill positions from our community.

Each week we highlight some of the recently posted openings. Check out this week’s newest, below…

If you are a great product person looking for a great product job, or vice versa, check out our job board. Thousands of employers across all areas of product, from management to design, from digital to physical, are looking to fill positions from our community.

Each week we highlight some of the recently posted openings. Check out this week’s newest, below…