AMA: Okta Product Marketing Lead, Ivan Dwyer on Technical Product Marketing

I’m not allowed to say Stripe. Everyone says Stripe. So I’ll say…. Stripe? I kid, I kid. I’ll always have a soft spot for Heroku – they’ve always stood out to me as a company with a unique brand presence that never compromised on technical value and authenticity. Some of the Product Marketers I looked up to most when first getting into the dev tools/cloud infra space came from Heroku. A newer company I’ve had my eye on that I think is doing a fantastic job in this regard is WorkOS. Simple and clean – very direct to the job-to-be-done. But beyond that, they’ve hit a strong narrative that counters DIY as the alternative. Something tech products always have to fight is the natural inclination to build this yourself (whatever *this* is). One look at WorkOS and it’s clear – that’s not something anyone wants to do themselves. That’s solid positioning right there, something they can build on as they grow. Outside of my technical area of focus, I’ve been following a lot of the newer class of collaboration tools like Figma, Airtable, Notion, Coda, and Miro. What I especially like about these companies is how they’re using community-generated content as a flywheel for adoption and growth. I really see that as the next frontier for the new class of tech products – as the community becomes experts and contributes content, new users can easily consume as examples, the flywheel spins and spins!

I’m a huge proponent of Jobs To Be Done, both for building products and for marketing products – in product marketing, though, you don’t necessarily have to be able to do the job of your audience, but you most definitely have to get it. I often joke that I’m just a good enough programmer to know I shouldn’t be one. What this really means (aside from being a really bad joke) is that I can write about *it* and hold a conversation about *it*, so I can be an effective marketer to those who do *it*. Now *it* has changed for me over the years – I’ve worked on dev tools products, cloud infrastructure products, and security products – as a generalist, I can carry my own in each of those areas, but wouldn’t trust myself a single day on the job! So generally speaking, this means that the types of skills to develop as a PMM are more about scratching the surface across the full technical discipline rather than getting really good at one specific area. For example, cloud practitioners may seek out a series of AWS certifications to up level their depth, but as a PMM only really need to know the key elements of the vast service catalog and what they each do. Where product marketers thrive above the hard tech skills is being able to speak to complex technical topics in a simple and elegant manner. Base level understanding is table stakes, but positioning is where your focus will have more impact and where you will be more noticed. So how much technical depth do you need to effectively differentiate your product? That’s exactly how far you should go in that area, no further.

I should have a better answer to this than Twitter, but I haven’t actually hired for that role in a long time, so might be out of touch, sorry! One thing I’ll say, and this might be a bit controversial, but I’m personally cautious of high-profile developer evangelists. There is absolutely a ton of value in building a public profile, and the role lends itself to community, but a strong advocate is someone who spends more of their time talking with customers, less time talking with other evangelists. The best ones I’ve seen balance this very well, all grounded in being helpful – engage with the community to drive awareness and interest, and engage with customers to drive projects forward. Depending on the nature of your product, folks who have historically ran user groups are often the best evangelists – they have a genuine passion for the technology, know how to bring people together, and have a knack for being public-facing. Might be useful to browse some adjacent meetups/user groups.

[Insert “Why not both?” meme] :) The best thing you can do is bring these stories together – when technical value solves business value, you have yourself a winner. (I don’t think I’ve ever encountered the inverse of that, now that I think about it) This manifests itself in a number of ways, but you almost always needs an explicitly budgeted project to attach to. Thinking top down – execs who mandate certain initiatives send managers out looking for technical solutions. When a practitioner tries a product out and gives it the thumbs up, that works its way up the chain. Thinking bottom up – when a practitioner finds a product that solves one or more of their responsibilities, they’ll make the case to their managers who get an exec to drop it into one of the project budgets. That’s an oversimplified view, it’s never that straightforward a path, but the main point here is that business value and technical value should be two sides of the same coin. Smart buyers know that – you don’t hear, “nobody got fired for buying IBM” anymore, companies do their diligence. As a PMM, it’s about identifying the motions – first, what are the compelling events that lead to budgeted projects? Then you want to land messaging that speaks to the value for the business owner responsible for the results of the initiative, and land messaging that speaks to the value for the technical practitioner responsible for the implementation. Easy, right?! :) I wrote about this topic in more depth here (https://www.workinproduct.com/blog/elements-of-a-positioning-system-compelling-budgets) – the next post was supposed to be about value drivers, but I had to put a pause on the series. Now I’m motivated to wrap it up, thanks!

Good question – it can depend on a few things. In many companies, you’ll have to wear both hats... I know I sure have. As Product Marketing teams grow, where it starts to break out into dedicated roles is at the target persona level – your more traditional PMM may focus more on the executive personas/solution marketing/business value route, while your more technical PMM may focus more on the practitioner personas/example use cases/how to guides route. If you're trying to figure out your own path here, one could either look to double down on one area or improve in others to gain broader coverage. More tech-centric PMMs have a lot of depth, but may lack the big picture, so it's beneficial to spend more time with folks on the strategy/GTM side of the house. More traditional PMMs know the fundamentals well, but may lack depth, so it's beneficial to spend time with folks on the product/Eng side of the house.

Great question… this is easy to over index on either side – too much buzzword bingo or too deep in the weeds. Personally, I like to follow a narrative from top to bottom – anchor to “the what”, hook with “the why”, and win over with “the how”. But each section in that narrative has to be punchy and unique. I’m a Rule of 3 type – bullet points, icons, lists, etc. I get reinforcing key points, but nobody has time to scroll through the same statement over and over again! On each... Personally, I care more about making an association with “the what” than trying to get creative. Just be prescriptive about what this product is to frame the rest of the content. I roll my eyes at abstract, meaningless website headers :) Getting to “the why” is where I place most of my focus – this is where being punchy and unique is extra important. I like to speak to pain points, but not in a negative, condescending way (ahem, many security product websites, ahem), more in an encouraging way. As I’ve written about with personas here (https://www.workinproduct.com/blog/elements-of-a-positioning-system-part-2-customer-personas), I try to appeal to what the audience is on the hook for, helping them get by and/or get a head. I don’t ignore “the how” – technical buyers need to be able to envision how your product works, not just in isolation, but with the rest of the tools & stack. This should be more visual than anything else. And it probably goes without saying, but backing everything up with great documentation is always a winner – easier said than done, takes a lot of dedication and diligence. But pays back in spades. Hope that helps!

Great question, I get in arguments about this all the time! Heh. You ask the question the right way - it’s about balance. Starting with my least favorite topic – SEO! The benefits of SEO isn’t lost on me, but for technical products, authenticity trumps all IMHO. I always cringe when I come across a bland, “what is [tech topic]?” blog post. I would much rather land on a “how to do [tech thing]?” blog post. But the best lesson I ever got in marketing was, “if you don’t cringe just a little, you’re not doing it right.” For those two examples specifically, the “what is” posts should be targeted towards the high value keywords that fill the top of the funnel, and the “how to” posts should be targeted on the long tail examples that get people through the funnel. Now at volume, though, those long tail posts become both SEO winners and useful examples in one. That’s the dream, it just takes time. Balancing internal enablement/external facing content is another tricky one. Personally, I get pulled in the enablement direction more than anything else, but there’s so much outbound content I’d rather be working on. I’ve tried to knock ‘em both down with a single piece, but that hasn’t really panned out the way I hoped it would – content really needs to be written specifically for the audience. Because this really comes down to priorities on both ends, I do my best to create content that hits as much of a “one to many” as possible. That’s especially important with enablement – my field organization is well over 1,000 people so I have to be extra diligent to not get pulled into a personal “one to one” training scenario. Which gets to channels – “one to many” is pretty important here, too, but in a focused way. I look for communities over anything else – tech publications are okay in the commercial sense, but all too often I feel like I’m just throwing content over the wall. So that’s a long answer that basically restates your question that it’s about balance – but I hope some of those examples were helpful!

Great question that's very top of mind! The broader GTM organization will own the growth targets, while the broader Product organization will own the adoption targets. I believe where tech PMM can make the most impact on both sides of the house is with velocity targets. On the GTM side, that's things like sales cycle velocity. On the product side of the house, that's things like onboarding velocity. The content that gets created by tech PMMs should be an accelerator, so the KPIs should match accordingly. 

Great question, something I think about a lot. I’m a huge proponent of specialization with technical products. I wouldn’t expect every member of our enterprise field organization (which is in the thousands) to be able to carry a highly technical conversation from end-to-end, nor would I want them to! But I am responsible for dev and ops-centric products, so it can't be ignored. What I try to do is zoom out of the customer lifecycle, pinpoint who on the team is having the conversation, and what they need to do to get to the next phase effectively – then I craft enablement for that, and that only! A lot of that is just asking the right questions – SDRs should be asking the questions to make sure they’re talking to the right person, AEs that there is a budgeted project to attach to, SEs that there is technical fit. But where rubber meets the road, the best case scenario is to have the practitioner persona matched directly with a technical specialists on the first go around – you lose folks when it takes 2-3 meetings to get to that point, or you lose folks when you try to pitch something you don’t understand in the first meeting. So my recommendation for sales enablement is to be very prescriptive by role – what they need most is a conversation guide that tells them what questions to ask and how to interpret them, and then how to move the conversation forward and with whom. While some reps have the natural tendency to want to carry it all the way through, they should be incentivized to bring in specialists where applicable – make it a win-win, and you avoid any objections to enablement guard rails. One area where I’m placing a lot of my focus is connecting the dots between product-led growth and enterprise sales. I have some thoughts, but still forming a clear hypothesis. Here’s a great post I read on the subject from A16Z (https://a16z.com/2020/07/29/growthsales-the-new-era-of-enterprise-go-to-market/)

I have a fairly extensive persona methodology which I wrote about here (https://www.workinproduct.com/blog/elements-of-a-positioning-system-part-2-customer-personas). Rather than get prescriptive with an explicit example here, I’ll share something I run i nto a lot that I think gets it wrong – bucketing CTOs/CIOs into the same “Technology Executive” persona. There may be some overlap, and it’s tempting to consolidate profiles, but in any modern organization, these jobs are vastly different, and should be treated as such. Both are responsible for making company-wide technology decisions, but CIOs make internal IT decisions, and CTOs make external production decisions. Their teams cascade differently, too – an IT Admin has a much different job than an SRE. The most important aspect of my persona methodology is really understanding what the person is on the hook for – both CIOs and CTOs have SLAs related to availability, resilience, and security (among other things) of infrastructure and software. CIOs have an SLA internally with the company, CTOs have an SLA externally with customers. So I’d recommend going through a persona building exercise with that distinction in mind – the specifics will play themselves out accordingly.