Main takeaways:
- Learn why preparedness is your most important virtue
- How communication can make or break your product and how to manage key relationships when team members aren't in the room
- Practical tools for maintaining focus and navigating the unexpected in your day-to-day
20. Importance of face to face communication
● Builds trust and rapport
● People are less likely to misunderstand you
21. Suggestions
● Work in areas with high foot traffic
● Ask questions in person when possible
● Participate in the office culture, go to events, lunch & learns, etc
● For remote teams, use video whenever possible
23. Tips for level setting with stakeholders
● Set recurring check-ins to review upcoming changes
● Be transparent about schedule
● Use visuals to engage and align
○ Clickthrough prototypes
○ Product demos (pre and post launch)
○ User Acceptance Tests (UATs)
25. “Never tell people how to do things. Tell them
what to do, and they will surprise you with
their ingenuity.”
— General George S. Patton
26. “When team members need to work together to reach a goal, brain activity
coordinates their behaviors efficiently. But this works only if challenges are
attainable and have a concrete end point; vague or impossible goals cause people
to give up before they even start.”
- Paul J Zac, Director, Center of Neuroeconomic Studies
The Neuroscience of Trust, HBR
27. Collaborating with your engineers
● Bring the customer into the room
● Leverage data to demonstrate your why
● Empower by encouraging criticism
○ Earlier is better
● Vague requirements, clear objectives
29. Risks of poor task management
● Missing/forgetting important requests
● Sloppy execution
● Stress/Burnout
30. Handling task management
● Keep a personal backlog
● Delegate (when it’s appropriate)
● Assess priority, then level set with the requestor
○ Internal or external request?
○ How valuable is this task to our business?
○ What’s the level of effort?
○ When in doubt, talk to your superior
● Block out time for focused work
31. Tools
● Simplicity in look and feel is best
● What I recommend:
○ Trello
○ Google Keep
○ Post Its on my workspace
○ Moleskine
○ RescueTime
● Ask your colleagues what they use
33. Tips for mastering competency quickly
1. Seek out and partner with subject matter experts in each department
2. Question everything
3. When it comes to data, learn to be self sufficient
4. Come prepared to meetings
35. “There are essentially three ways for a product manager to work, and I argue only one
of them leads to success:
1. They can escalate every issue and decision up to the CEO. In this model, the
product manager is really a backlog administrator. Lots of CEO’s tell me this is
the model they’re in and it’s not working. If you think the product manager job is
what’s described in a Certified Scrum Product Owner class, you almost certainly
fall into this category.
2. They can call a meeting with all the stakeholders in the room and then just let
them fight it out – this is design by committee and it rarely yields anything
beyond mediocrity. This is very common in large companies, and in this model,
the product manager is really a project manager and roadmap administrator.
3. The product manager can do his or her job.”
- Marty Cagan, Author, Inspired
"As you checked in we sent you an email to join our online communities, events, and to apply for product management jobs. As members of the Product School community we'd like to provide you with these resources at your disposal."
I’ve been working in software development in some capacity for over 10 years now. My first job out of college was in 2008, I was a game test for guitar hero.
A lot of people think a video game tester is somebody who gets paid to play video games all day. And that’s sort of true but its a real job, it has real challenges. You have to have an eye for detail. But I’m grateful for the opportunities I had as a tester it exposed me to a lot of different roles in software development. It also taught me to empathize with the end user, right. That’s what a tester is, if you think about it, its someone you pay to use your product like a customer. Its where I learned that product management is where I wanted to set my sights.
And then Playsino, based right here in Santa Monica. In 2012 I joined up with them and this is where I transitioned into my first product role. I eventually became their Head of Product for a number of years.
During my time with Playsino I did some consulting work. Quickschools is one of the companies I worked with. And now I’m Senior Product Manager for Dun & Bradstreet, out in Malibu.
A “pitfall” then, is anything that gets in the way of you achieving the desired business outcome. I don’t want you to think that you have to be perfect. I’ve worked as a PM now for over 6 years. I’ve had rock star products. And I’ve had flops. You’ll have flops too. But my aim tonight is put a few words of wisdom, from my own experience, into your heads so you can save yourself a little bit of trouble on your journey.
A “pitfall” then, is anything that gets in the way of you achieving the desired business outcome. I don’t want you to think that you have to be perfect. I’ve worked as a PM now for over 6 years. I’ve had rock star products. And I’ve had flops. You’ll have flops too. But my aim tonight is put a few words of wisdom, from my own experience, into your heads so you can save yourself a little bit of trouble on your journey.
I want to kick things off talking about relationships. Relationships are the undercurrent of this topic tonight and they’re the undercurrent of your responsibilities as a PM. You can’t build products without them. Relationships with stakeholders. Legal, Customer Service, they have vested interests in the solutions you’re building. With engineers. With project managers. With sales. With engineers. The people building your solutions. With the customer, the people using your solutions. Relationships. I told you I have a background in the gaming industry so a video game analogy was inevitable. How many people remember the SIMS? Will Wright’s masterpiece? Sold over 170 million units?
Here’s tip #1 let people see your face. Let it be a habit every day to get in front of other people. Let their eyeballs meet your eyeballs.
The most obvious benefit of this, its easier to trust somebody you see. Its also easy to not like somebody you see but I’ll assume you’re all relatively nice people. Face to face interactions build trust faster. And people are less likely to misunderstand you. Communication is everything, guys. As product manager, we need to clearly articulate what we mean, we need our partners and colleagues to be in alignment with our intentions. If you’re speaking face to face you’re that person’s brain more to work with as they attempt to understand you. Your facial expression, the inflection of your speech, your gestures.
And if you’re working with a remote team, try and visit your team a few times a year. And take video calls over voice calls.
Let people see you face. I have a few suggestions.
What happens when you don’t set clear expectations with your stakeholders. Do they feel good?
Be there for your stakeholders. Be their champion. Really. Because what is a stakeholder? If someone is a stakeholder on a project, you are working on something that affects their success. Think about the weight of that. That’s a big deal. That person trusts you to have their needs in mind. If I’m the head of Customer Service, and 40% of my customer complaints are about a tool thats frustrating to use, I can’t fix that tool, I don’t have an engineering team. I need a product person. Can I trust that product person to listen. To understand my point of view. To craft a solution that I believe in, even if it takes some convincing.
Set check ins. Stakeholders like to be involved. And they want updates. Find a cadence that works for everyone. You want to meet often but also be respectful of peoples time.
Every stakeholder should be aware of where their interests lie on the roadmap. Sometimes this is the job of a program or project manager, who handles the operations of the technology team. But you’re accountable even if you’re not responsible. So make sure the stakeholders know whats going to production and when.
And when possible, don’t explain what you’re building, show what you’re building. Let them click through something if possible. It makes a difference. Its confusion proof.
When I say don’t give order I’m talking specifically about the team responsible for building your code. Product Managers don’t run the technology team. One of the worst things you can do is hand a requirements document to an engineer and say “I’ll see you in 2 weeks, let me know if you have any questions.”
You’re a product owner but guess what your engineers they’re product owners too. And if they don’t feel that way, its your job to inspire that. Because if an engineer isn’t engaged with what she or he is doing they’re going to cut corners. They’re going to make bad decisions. Your UX will suffer. Trust me. Because you can write the most detailed set of specs imaginable, but the engineer will have judgment calls to make regardless that you don’t see, at the point of execution. And if they aren’t clued into the flight plan there’s vast room for error.
In a recent issue of Harvard Business Review Paul J Zac ran a series of experiments on the release of oxytocin and its correlation with trust in team building exercises. He found that “”.
You have to share the why with your team.
Bring the customer in. Use verbatims. Theyre very effective. Use data. Set the stage for your engineers. Present the business case. Present the dollars and cents. Their paycheck depends on the success of the business, The satisfaction of the customer when they engage with the things that you build. Teach them that. Show them that. And use data. Engineers love a story you can tell with data.
Something to watch out for. If you’re presenting a new feature to your engineers, and the room is quiet, you’ve got a problem.
The longer you work at a company, and the more domain knowledge you acquire, the more people are going to come to you. To ask questions. To make requests, For help. Its a very natural thing. And its positive reinforcement that you’re building the right reputation among your colleagues. You want to be a subject matter expert on your product. Of course you do. But the other side to this coin is when the outside requests run the risk of impacting the day to day needs of your product work. I used to start my workday at 9am. And this is how my day morning would start.
This is a pitfall. You want to be helpful. Being helpful is how good employees become great employees right? Its like discretionary effort. You want to be a superhero. But you also have deep accountabilities. To your stakeholders. To your customers. So where’s the middle ground? Where’s the compromise?
As these one off requests start to pile up on top of your key responsibilities things can begin to get overwhelming very quickly.
TALK ABOUT RISKS
For starters, keep a personal backlog. And prioritize that backlog. And be wary of favors. This may take some getting used to but NO is a pretty important word in a product managers vocabulary. I say it a lot more than I say yes. If someone asks you a favor, someone you’re close with, and its a cool idea, you like the idea, and so you agree to help out, and consequently push out some other task. A few weeks later the CEO wants to know why a feature didn’t hit its deadline. “Well we helped out so and so with feature X.” So? What value did feature X bring to the business? At that point you better hope you can explain away how feature X brought more business value than feature Y. That’s what it comes down to. So look at some of these factors “”
Marty Cagan, author of the book inspired, a product manager thought leader, someone I admire very much. Talks a lot about competency. And I can easily say that in my whole career working in product management, all of the different industry verticals I’ve worked in, large business, small business, your success as a PM hinges on competency. The relationships are the pipeline through which you share your knowledge. But if you dont do your homework, and you have no insight worth sharing, you’re dead weight. Your top priority when you start at a new company is to learn your market, learn your products, learn you customers. If you want to be the most confident person in the room learn until you now more about the product than your boss, and her boss. And then you can be of some real use.
I have just two more for you. We all know about the virtue of proactiveness in the workplace. As a Product Manager its crucial.
Its a slide full of text so I apologize for that but I love this because he’s so right. Build your competency, use that competency to identify opportunities, communicate your innovative solutions through the relationships you’ve established, and inspire your team to make it great.
Last one of the night. I made a point earlier about faces. Here’s another one. Don’t take things at face value. In my experience, people don’t always know what they think they know. Remember “question everything?” You don’t make assumptions, but other people do. User your conversations with others as launching pads for your own due diligence. Be resourceful, run things by your subject matter experts. The last thing you want to do is give someone undue credibility, let their opinion inform a criticial decision which you then execute on; the next thing you know you’ve built something that benefits the customer but makes more work for one of your stakeholders or vice versa. See what I mean?