sampling of some points about my journey: ⚛ Mainly non-technical, business background ⚛ Analytics/Business insights + UX optimization focus ⚛ Financial services and Government market segment expertise ⚛ B.A., Political Science, University of Wisconsin ⚛ M.B.A., Southern Oregon University ⚛ Many years spent in UX research/market research/political polling/Ad testing Some Good On-Ramp Careers to Find Junior PM Candidates: ⚛ Equity research ⚛ Market research ⚛ Copywriting ⚛ Project management ⚛ Management consulting ⚛ Auditing ⚛ Grantwriting 2 Building and Scaling PM Teams I don’t know much, but I’ve seen a lot.
different depending on the product or the environment. • All the typical descriptions (CEO of your product, single throat to choke, Conductor of the orchestra) kind of obscure the main goal: make money. • If you don’t know what your product is expected to do from a revenue generation perspective, you need to figure that out first. 3 ” Building and Scaling PM Teams
It’s incredibly important to hire first for fit, then for horsepower, then for hard skills or domain knowledge. Especially for Product Teams where it’s primarily a relationship-based role. If your team culture gets away from you, you’ll never get it back and it’s immensely difficult to reboot without starting over. This is not an encouragement to hire with cultural blinders on: fit doesn’t mean making the team feel the same as it does today. Fit means the people you hire need to raise the game of the rest of the players without the need to explain why your team is the way it is – they need to just get it. You can have an extremely diverse team that have very tight cultural fit. 4 Building and Scaling PM Teams
business needs into features, engineering limitations into boundaries, timelines into roadmaps, business cases into product plans • Organization – meetings, stakeholders, work items, user feedback • Flexibility – project manager hat when necessary, being the designer for a stretch, extending the development team’s capacity if possible, working with support, learning new things at light speed • Execution – measure success and visibly advance towards it • Horsepower – the job doesn’t always have an end or a beginning, the engine needs to be running 100% of the time. The list goes on, but these are the ones that really matter. 5 Building and Scaling PM Teams
if not – it’s not an absolute predictor of success in my experience • Certs/Education – If you’ve got it and can apply it well, it can be an asset but doesn’t always mean you can put your education into practice • Domain Expertise – We all think that what we sell/build is so special nobody can understand it like we can – this is false and can be harmful to growth • Martyrdom – If you’re willing to die for the product you’re willing to die – I need PMs who can do the job and stay afloat, happy, and sane 6 Building and Scaling PM Teams
individuals (or teams, if larger scale) to own a sole product – increases accountability Flexibility in assignments Can create progression pathways CONS Can create unhealthy competition if done poorly Some may think they’ve been assigned less sexy products SMEs: PROS Aligns to existing strengths Can help teams grow quickly Builds individual trust and accountability CONS “You don’t know the problem space like I do” Boredom Low cross-pollination Key person/knowledge concentration risk BA>>APM>>PM>>SR PM PROS Good for stricter HR departments who prefer rigid grade levels/salary bands Clear progression Division of labor can be easy to lay out CONS Title envy Fun hoarders Business analyst can be hard to hire for, too general to attract interest Overlapping T’s PROS Strong alignment on the basic skills Allows the team to operate from a position of common strengths Team members can deepen their T without much issue CONS Too much overlap can cause territory problems Allowing someone to go so deep they go into SME-land, never to return Hiring someone with no T to begin with = direction issues 7 Building and Scaling PM Teams
it’s not necessarily as applicable. With good overlap, you want some duplication of individual team members’ depth, but not so much that you’re duplicating their strengths. If you wind up with some gaps, that’s okay, but then the question becomes: are those gaps going to becomes strategic weaknesses over time? 9 Building and Scaling PM Teams
Fey quote and I think it lends itself well to what we do: we need smart people to think for themselves, make the right decisions, and drive to outcomes. The risk of hiring the wrong people is significant, and if you can’t imagine yourself taking one big step back from your teams day—to-day and letting them individually run with their work, reassess your team and your own approach. Product teams necessarily thrive on a very macro management style, no matter what you think your strengths might be or how exacting your standards might appear. Give your teams some room to 10 Building and Scaling PM Teams
plays Waterperson model – Support the team where they need it most Convergence Point – Help the team decide what to do and how, select from competing alternatives Protector/Promoter – Keep the team protected from value negative BS, promote their work and wins Hybrid 11 Building and Scaling PM Teams
solve every problem with design, engineers will try to solve every problem with backend heroics, PMs-by-extension will try to solve the problem with headcount (hire a consultant to fix, hire a design consultancy to fix, hire a contractor to build). You’ve got to know yourself, your limits, and your strengths to excel at this. Anyone who just has pure ambition is wrong for the job. They need to be in-touch people. 14 Building and Scaling PM Teams
style second, and your taste in wallpaper third TO HIRE: Have a bias for driven, ambitious doers aka ‘Hire for Horsepower’ 1-3 years of work experience in any industry to avoid having to teach the absolute basics (email etiquette, how to set up a meeting) Avoid seasoned PMs looking to make a stack/industry/segment change at this stage – we’re aggressive people by nature and there can be a “well this is how we did it at Acme Corp. and we were a $5bn company” issue that may hinder more expansive thinking. Better to hire PMs with good experience in your exact wheelhouse with a PM title at a junior level and grow them. Hire someone who could replace you +5 years out TO AVOID: Designers who have done “some product management here and there” Engineers/devs who think they’d be good at the job because they’ve got big ideas and like the visibility (at least not yet – these people can come in handy later on) Anyone who hasn’t gotten their hands fully dirty in awhile ⚛ Oftentimes, non PM’s people see “Product Manager” in the title and think they’re going to manage the work of others like a shop boss, kicking back and pointing out errors Anyone who lacks self-awareness Depends on the size of the team, but typically you want, in order: 1. A data pro – Data drives good product decisions, you need to wrangle it to use it 2. A process cop – New teams tend to be light on process, get someone who can impose some structure, artfully 3. A design/UX person* – You won’t need to make it look pretty until it needs to look pretty 15 Building and Scaling PM Teams
to things that you may not understand well 5. A junior manager – If your team is scaling, you may need help making decisions – don’t be a bottleneck 15 Building and Scaling PM Teams
features A PM that can’t connect the features to the $$$ is not going to work out Avoid hiring people looking for startups, but settling for your company/team Avoid building fighter jets if you’re in the Cessna business – you may outpace your customer Startups/Smaller Shops The do-it-all PM can thrive in this environment Hire for breadth, not depth Customer-facing conversations happen a lot at this level, so must be a good connector/conversationalist They’re going to want your job, another job, or eventually to leave Burnout happens – have a deep bench until things mellow Enterprise Product teams are a newer idea in this space – execs don’t always know where they fit Larger companies are occasionally averse to having “manager” in a non- people-manager title Product teams need tools that large enterprise tends not to want to buy (Trello, Sketch/xD, Asana, Pendo) Most large companies have an inconsistent approach to Agile, which can cause complexity in execution and roadmapping You as a manager must visibly, and vocally empower your team to make big decisions in your absence 16 Building and Scaling PM Teams
savings on its face, but without proper preparation and internal understanding, its doomed to cost you more in the long-run. Enterprise considerations: 1. What’s your contracting process look like? Vetting and getting FCPA/Internal risk teams to clear a foreign firm to work with you can be time consuming and burdensome if you’re the first to do it 2. Do you/can you set up an IP tunnel? 3. People are going to balk at sending you/your team to a foreign country with any regularity if they haven’t before. It’ll seem like an excuse to travel to them because they don’t see the need. It is IMPERATIVE that you go on-site once a year at minimum, and ideally once a quarter. If you can’t find the budget for that, explore alternatives. 17 Building and Scaling PM Teams
nothing is important ExecuCution Team – Becoming the execution team for [EXECUTIVE]’s ideas/plans/shower thoughts ⚛ Can work if exec will listen to user feedback/data ⚛ Saying NO every time can be career limiting, saying YES sometimes can work Forgetting the V – MVP = Minimum VIABLE Product, not whatever we could build in time to meet an arbitrary deadline (consider instead MMO) Death by Operations – Your team finds itself doing sales operations, implementations, integrations, and project management more than talking to customers 18 Building and Scaling PM Teams
blevine
akippa
tbpgr
jack0522
tanashu
pokotyamu
kimpachi_d
kakehashi
polipoli
ryo_nagata_
ktkn1129
mirairohr
mercari_inc
swwweet
ddemaree
reverentgeek
robhawkes
zakiwarfel
tenderlove
iamctodd
akosma
aki_iinuma
mongodb
thekraken
edds
