Working with Product Marketing

Leave a comment
Growth

Positioning, positioning, positioning

The best software doesn’t sell itself. Even if you did have the best software, it needs to be positioned, priced and pitched correctly to stand a chance amongst your competitors, and that’s where product marketing comes in. As a manager of an engineering team it’s likely that you’ll be regularly working with a product marketer to make sure that the cool stuff that you’re building is making the biggest splash possible.

Great product marketing can make the code you’re writing into something that people need to have. This is most easily demonstrated by example. To begin with, consider this: a customer messaging platform. Sounds boring. But by using Intercom, and especially when perusing through their wonderfully designed guides, you’ll wonder why you didn’t start using it sooner. Now consider this: yet another instant messaging program. Yawn. But after having a read through the beautifully written and illustrated Telegram blog I was downloading their app and I’ve been using it ever since. It makes a lot of difference. A world-class engineer, designer, product manager and product marketer can really change the world.

In the wider world beyond software, clever positioning of a product can dramatically widen its reach. For example, Cirque du Soleil are not just positioning themselves as a circus act. They are a brand that compete against theatre, movies and musicals worldwide.

So what is product marketing?

Product marketing is a really interesting role. It’s a kind of hybrid of product, sales and marketing. Small SaaS companies may have just one product marketer for their application. Large companies may have one product marketer per tool in their suite, or they may have many product marketers producing content to appeal to particular user personas.

As an engineering manager, product marketers are extremely useful to make sure that your team are iterating quickly on the most impactful features, that they are getting feedback from users quickly and therefore experiencing the true impact of their work. We’ll have a look at how we can help them help us shortly, but first let’s explore their role.

So, what do product marketers concern themselves with?

  • Creating a compelling narrative and positioning for the product that you are building. Why does this product exist and how is it making its own ding in the marketplace? Why is it so much better than competing products? Why is it so much better value for money? They have the answers to these questions.
  • Deciding the right moments in time to make big marketing pushes for big impact. Your product may have new features and functionality added weekly, but when is the right point of the year to turn the wheels of the hype machine and do a big, splashy launch? When should they spend marketing budget on creating an advertising campaign? How does that line up with what the rest of the company is doing and with competitors’ launches?
  • Engaging with customers and tracking usage of features. Your product marketer will obsess over how new functionality is being picked up when it hits production and will keep a close eye on feedback, whether implicit or explicit. They’ll reach out to your biggest customers directly for feedback. They’ll worry when few people engage with your latest product feature and want to help you fix that problem.
  • Steering sales enablement. Your product marketer will be the biggest champion for your software and will spend plenty of time narrating the story and purpose to the sales team. They’ll do demos for them, run sales enablement sessions, get them excited about what’s coming down the pipe, and give them hints and tips on how to sell against competing products and how to get the most out of your new features.
  • Advising on pricing. It’s extremely hard to get pricing right in an ever more price sensitive economy. Your product marketer will eagerly study what your competitors are charging and what their billing models look like so that you can have the best chance of fighting them.
  • Feeding back from the marketplace. Your product marketers should be sitting in on sales pitches, demos and executive business reviews with your key clients, listening to their needs and then feeding it back. As well as bringing products to market, they should bring the market to the product.

Helping them help you succeed

As you can see, product marketers do a lot! They’re invaluable resources for your team, connecting you with customers and further convincing your own engineers of the over-arching purpose of what they are building.

But this seems a world away from engineering management, which is your job. Is there anything that you can do to help them do their job better and therefore make your team’s work even more successful? Well, fortunately, there is a lot that you can do.

Let’s explore how you can help.

  • Find the product marketer(s) who are working on your area of the application. Your team and department may already have strong links with those that are doing product marketing, but it’s equally possible that they sit in another department, or on another floor, or even in another office in another country. How often do you meet with them? There may be a lot of disconnect between the engineers writing the code and those weaving the narrative. Find them, introduce yourself. Take them for a coffee if they’re nearby. Ask them how they do their job. Ask how you can help. Enquire as to whether they have any frustrations. Even better, see if they can come sit with your team on a regular basis to form a closer bond.
  • Include them. Open up your world to them. Invite them to your sprint demos. Get them in your Slack channels. You want to have a fluid, open conversation going at all times. See them as an integral part of your team. This gives them the chance to offer feedback (from themselves and also customers) at the earliest possible stages, creating the opportunity for them to motivate and steer the team.
  • Describe the reasons you think that you product or feature is awesome. Your team will work on more than just customer facing features. They may improve uptime, speed or the number of concurrent users that your application can handle. These aren’t always clear to your product marketers, but they are great ammunition for them to further improve their message.
  • Let them practice their narrative with your team. Not only does this give the chance for them to have a safe space to craft the ongoing story of your features and receive feedback, it also gives them the chance to expose the impact of the work that your team is doing. This is extremely motivational and breeds a feeling of purpose and desire for your team to do their best work: it really means something!
  • Build in feature toggling. For the greatest possible market impact, your product marketer may advise batching together the unveiling of a set of new features and launching them as part of a campaign. You won’t want to hold back code changes indefinitely, as continued code changes can end up blocked behind stale code that hasn’t yet been released. Instead, build in the ability to feature toggle and keep shipping to production in secret. We’ve had great success with Launch Darkly, which allows code to be wrapped in feature flags that can be turned on and off dynamically. It can also do targeted or percentage-based rollouts; ideal for enabling features for trusted clients for early feedback, or letting your company’s employees use the most bleeding-edge features.
  • Track usage. Always call upon your product marketer when designing new features so that you know what the important metrics are that should be tracked. Is it clicks or opens or conversions? Is it session length or actions performed? These tools give your product marketer greater power in investigating how well features are being received.
  • Build in survey functionality. This could be as simple as a net-promoter score prompt that appears occasionally in the application, or could be a detailed survey that is delivered to users quarterly.
  • Let them talk directly to customers. Again, Intercom has been an excellent tool for this. As well as telling their narrative via marketing material, we’ve been using Intercom to let our product marketers deliver product updates, targeted messaging and receive questions and feedback directly from customers through the application. Doing so requires no intervention from the engineers.

In summary

If you’re running an engineering team, then having a good relationship with your product marketers can help you make your work land with impact at the right place and the right time. There are a plethora of ways that you can help make life better for your product marketers, and it’s in your team’s best interests that you do.

Make sure that you’re getting the most from them: early feedback on product development, intelligence on your competitors, clarification of the value (to users, but also monetary) of what you are building, your messaging to the market, and help defining targets behind usage and interest. Go and use them!

Thank you to Phill Agnew for the comments and feedback on my draft of this post.

Engineering at scale is a people problem

Leave a comment
Growth

Building people and technology

When your company is at an early stage, hard graft, rather than complexity, is the focus. Communication doesn’t require careful thought or organization because you’re either sitting next to each other or there are few enough of you to make decisions over video calls, emails or IMs. If there’s friction or disagreement amongst key people, then often the fight to keep afloat takes precedence anyway, dampening the urge to keep negotiating. Instead, you just do.

For the lucky few, dreams of success at those early stages can become a reality. That reality can be one playing out in fast-forward. Your company could attract funding and grow aggressively, expanding into many geographical locations and in turn create multiple products that each generate their own revenue streams. That’s all brilliant. But success and scale also cause drag: communication gets harder, collaboration becomes trickier and decisions require much more lobbying and consensus. Trying to continually adapt how the department works as it grows and matures is a continual iterative process that you’ll get wrong more than you get right.

From a technical viewpoint, as a product and company grows, so does the complexity of adding new features. In the early days where only a handful of developers were required to build the whole thing, decisions and progress were fast. But now building innovative new features often requires a multi-team effort: provisioning of new hardware or infrastructure, plenty of data science to prove concepts, new APIs and services built with future reuse in mind, and sweeping changes to the UI.

It becomes harder for each team to cleanly and completely own an area of the application. Dependencies begin to occur between different areas of the department and communication becomes more complex. You could argue that the hardest part of having a successful technology company is solving the technical challenges, but when it comes to doing this at scale it’s more often than not a people problem. How can everyone remain productive as the department steadily grows? Are there set processes and techniques that we can use to make this all predictable and frictionless?

Process isn’t always the answer

Being engineers at heart, we often try to solve all of our problems in the same way that we try to solve the problems that we have with technology. Surely, if we can streamline algorithms and build processes we should be able to apply the same logic to problems in the domain of communication and productivity, right?

Well, sometimes.

If we’re not careful then we can end up layering more and more complexity on top of what are essentially people problems and then inadvertently create even more people problems as a result. It’s a vicious circle.

It is sometimes necessary to take difficulties in the department and assess them as people problems rather than process problems to see if there are far simpler ways that they can be fixed. Let’s have a look at an example that we worked through in many iterations at Brandwatch. We still don’t have a right answer, but I feel that it highlights how we incorrectly identified a people problem as something that could be solved with even more process when the solution was in fact far simpler.

Pull requests

For many years I’ve been involved in reviewing code. This example covers how we worked through some issues with scaling backend code review as the department grew.

If you’re not familiar with them, pull requests are a method for submitting modifications to a codebase via Github so that others can review them before they are merged in. We’ve been using them for many years, and they’re great. However, when we first adopted them it took a number of adaptations to the way we used them before frustrations went away.

Let’s start with some history.

A very long time ago, in a pre-Github era, there weren’t many developers in the company. Typically people would ask for a quick in-person code review before pushing their work into the testing environment. Although an imperfect process, it encouraged people to seek review themselves before their code went any further. However, as we grew, and as the pull request functionality in Github became a lot better, we migrated to that system because it made it much easier to organize detailed reviews, especially when the number of developers in disparate geographic locations began to increase.

However, the pull request process highlighted a multitude of ambiguities in how we got things done:

  • How many people were required to review a given change before it could be merged in?
  • How senior did the reviewer need to be so that the review could be trusted?
  • Who was allowed to click the “merge” button once the reviews were complete?
  • How were conflicts resolved if the reviewers didn’t agree or if the submitter disagreed with the reviewers?

Mergers

In order to answer these questions, we added another layer of process: a group of senior and trusted developers called mergers, who had the authority to decide the fate of a pull request and ultimately were the ones that were allowed to click the “merge” button. Our new mergers enjoyed the initial responsibility and spent much more time carefully reviewing code. Two reviews were required: one from the merger and another from any other developer.

However, with time this additional layer of process created more people problems:

  • Our mergers became a single point of failure and if any of them got busy or sick then the throughput of teams suffered.
  • This also increased the amount of pressure that our most senior developers had on their job: they were now slowing up the rest of the department if they were busy with their own work!
  • Those that were not mergers felt like they had diminished responsibility. Not only did this make them feel like they were not trusted enough, it also dramatically reduced the amount of time that they spent reviewing code because they felt that a merger would need to do it anyway, so why bother?

SLAs

Of course, to solve this problem, more process was added! We implemented an SLA for pull request review which mergers needed to stick to.

This made things worse:

  • More pressure was being put on the mergers to review quicker.
  • The SLA was being observed regardless of the size, complexity or impact of the pull request. Some bug fixes take 30 seconds to review, and some architectural pieces can take multiple days.
  • Our delivery managers would chase pull requests that weren’t meeting SLAs, causing even more stress for our mergers. They started to really hate the responsibility.

Easing the grip

After a while, it was clear that our issues with code review were people problems. I reached a point where I felt I was spending too much time in the week addressing problems that the code review system had caused: stalemates due to disagreement, pressure from the business about things being “too slow”, angry staff who felt powerless to get their changes through, endless cyclic arguments from code style to personality clashes.

It was time for change. Fundamentally, regardless of process, we wanted to aim for the following:

  1. Everyone should feel empowered to make changes to the codebase.
  2. It should be in the best interest of the submitter to get their changes reviewed and merged. They have ultimate responsibility for the progress of their review.
  3. We trust that each engineer would submit their best work for review and would not want to do anything destructive or malicious.
  4. We trust everyone to give suitable constructive criticism, no matter their seniority, and to do their best to prevent bugs or odd patterns making their way into the code.
  5. Regardless of what happens, it’s just code after all. If something causes a bug when it gets merged into the codebase, we can just fix it or back it out. No big deal.
  6. Two positive reviews and it merges. No specific mergers required. The submitter should feel empowered to nominate reviewers if there are specialist concerns.

We’ve operated with this model since. It still has its flaws, but for the size we are now it makes do, and requires very little policing or intervention. It allows most review to happen within teams, too.

Redefining what we wanted to fix as a people problem showed that none of these ambitions required monitored implementations of particular processes. Instead, we just needed to encourage people to feel empowered to get on with their jobs to the best of their ability. And best of all, it had entirely positive effects. More people became empowered to get involved in reviewing because they could affect the outcome. Teams felt like they could take more control of their destiny by reviewing the code of their teammates rather than relying on nominated engineers in other teams and locations. And, when very complex or controversial pull requests were opened, people actively sought reviews from the right people themselves because it was in their best interest to do so.

In summary

Before you add another process or piece of technology to solve an issue, stop and think: is this a people problem?

Although it can be tempting to use one’s engineering brain to solve issues as if they were an algorithm, often that isn’t what needs fixing. In our example, an increase in trust and autonomy of individuals made people work more efficiently, rather than trying to layer on more process. We are just humans after all.

Workplace politics

Leave a comment
Growth

How things get done

We’ve all heard about workplace politics. What are they? Are they good or bad? Can we prevent them or should we get involved? Let’s spend some time exploring them.

Work, as in life, is filled with many independent actors in a complex system. Each actor is motivated by differing interests, passions and values. Each is working independently towards the greater good of the company, and politics are what arise from the continual negotiation, persuasion and debate of ideas.

The term workplace politics has often been used to describe purely negative situations such as those being taken advantage of, proverbial backstabbing, or people being poorly treated and taken advantage of. I would say that is a subset of workplace politics: it can potentially happen, and it does, but it’s not the wave that you should be looking to ride. You can use politics for good.

Politics in the workplace are always going to happen. You can’t choose to not engage with them, because if you do not, then you will find that your career suffers as a result, especially as you spend more time in management. Instead, the art is to understand these politics to see how you can navigate them and use them to your advantage whilst at the same time being an open and transparent individual. Ego, power, unwritten rules and implicit culture unmask themselves at higher levels of an organization, and you need to be able to harness them with a clean reputation.

Let’s dig deeper into what they mean.

How do politics arise?

Politics typically arise because of tension between different types of social structures:

  • The org chart. The most obvious place where politics can occur. Debate between you and your boss about your own interests, or conflict between your and your direct reports. This also manifests in individuals reaching down or up through the org chart in order to spread their influence.
  • Close-knit informal groups. There will always be groups of people who are close to each other and protect each other through friendship, camaraderie or shared interests. They have no formal power structure in the org chart, but they lobby and work together.
  • Influential people. Singular influential people, who may have much more say than others because of their tenure, celebrity or bargaining power can make situations political or difficult to navigate because of the difficulty of building consensus without them.

As you spend more time in a managerial role, you will see how decision-making is rarely an easy task. You have to navigate the structures and people demonstrated above in order to make sure that things move forward in a constructive manner.

Like in real politics, all political situations and negotiations involve an element of risk. How should you conduct yourself? After all, getting politics wrong can be humiliating: you can find yourself looking very stupid, uninformed or unpopular in opinion. Getting involved in the wrong type of politics can be harmful, so you need to be able to protect yourself from the kinds of interactions that are toxic and only exist for those involved to be cliquey, spiteful and malicious. However, getting politics right builds your authority, influence and ability to get things done, opening up further doors in your career.

Positive politic patterns

Let’s explore ways that you should use politics to your advantage.

Learning teams and networks

Who makes decisions in your organization? Who is influential? Who are the close groups of individuals that think similarly, and who are the rival factions? Identifying this up front allows you to navigate sensibly through the political landscape and gives you the best chance of knowing who to go to in order to build consensus on particular issues, and who to approach differently or even avoid.

Take note of the different teams and divisions. What are their priorities? What motivates them? What do they care about and what are they knowledgable about? Which individuals have sizable influence and why? Is it because of their tenure or their technical prowess? By mapping out the organization and learning how it currently works, you can identify which groups and individuals you can collaborate with on different issues with the least amount of friction.

Winning hearts and minds

Remember that in order to have influence and to make an impact, you will need to win hearts and minds rather than just telling people what to do. Being a manager and therefore having authority to issue instructions and directives does not function well when the only delivery mechanism is executive order. You need to be able to make sure that the people you are leading really buy into what you want to propose; whether that is a critical decision on a project, a decision not to hire somebody, or a refusal to take some architectural work in a particular direction.

You need to be able to understand what motivates and drives people and to have the confidence to explain to them why¬†their work matters as well as just what it is. Those that aren’t immediately receptive are those that you should spend time with in order to reinforce your view.

Building consensus

As companies grow in size, projects and initiatives move forward through collective effort, rather than just the force of will of an individual. When working, you will need to understand that consensus – at least as much as you can get – is important. In small companies and start-ups you can just take the proverbial bull by the horns and do whatever you want alone with little repercussions, but larger companies are different.

You can start small and informal. Let’s use an example. If your team wants to do something dramatically different to the codebase for their next project, then it is important to take as many people as you can along for the journey at the same time. It’s likely that your team won’t be the first that have thought of doing something like you’re proposing, so start by having some informal conversations with those that are senior, influential and close to the matters at hand.

Assuming that informal conversations have been successful, then you can announce more widely that you’d like to try a proof of concept pull request, or even just write an idea paper for circulation. It’s important that those you initially talked to are able to sponsor your efforts and offer their support, and that any work that you propose is just that: a proposal. Build consensus by making others feel like they always have the opportunity to contribute to what you are suggesting rather than it appearing to be a mandate. It will unlock the ability to make wider reaching decisions.

Being your best self consistently

Appearances and interactions are very important. You need to be your best self in a consistent manner in order to ensure that you are able to engage correctly in workplace politics and represent your teams correctly and respectfully.

Always be open, transparent, respectfully critical and absolutely clear on where you stand. Have the confidence to be open to being proved wrong and to be fine if you are. Be open to disagree and commit to initiatives. Never push agendas for the sake of serving only one’s self. Fundamentally your means of conduct comes down to the Golden Rule: treat others how you would wish to be treated yourself, and set the bar high.

Additionally, remember that when you become a manager, whether it is right or not, your position in the org chart grants you more power and you must wield this power respectfully and wisely. In the game of politics you must make sure that your relationships with particular staff are never seen to be favorable or unfavorable for personal reasons, otherwise you can be seen to be cliquey or nepotistic and this will make you less trustworthy. This may require some difficult conversations between those you are friends with externally about how you can conduct yourself in the office, but you will thank yourself in the long run. You need to engage equally and fairly with all.

Building a network of peers

Previously we have talked about building a network of peers from different areas of the business in order to share information, get feedback and sound out your ideas. In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities, and it also gives you a chance to trial ideas before taking them any further, allowing you to initially operate in a safe, cross-disciplinary setting.

Negative politic patterns

In contrast to the positives, there are many negative ways that you can engage in workplace politics that will at best result in conflict and at worst have a negative impact on your career.

Misuse of executive order

Whilst your seniority may allow you to just tell people what to do, without winning hearts and minds, you will erode your respect and ultimately your influence. I like to imagine each manager having an energy bar, like in a video game, that is depleted when a controversial override on a decision is made, or an unpopular direct order issued. You must use them tactically and sparingly. The bar replenishes when you move forward with your team in a congruent manner where they are motivated to go on the same journey as you.

Level-jumping

I’m sure we’ve all been guilty of going over someone’s head to their manager because it’s quicker and easier than going via the chain of command. I’m sure many of us also saw how much trouble Jimmy McNulty used to get into in The Wire for doing so¬†(warning: very strong language).

Now, there may be times that this is quick, easy and convenient. However, the person being left out in the middle feels awful. There are things going on in their team or division that they are none-the-wiser about. Sometimes you may have a good relationship with your manager’s manager or even be friends outside of work, but you need to make sure that you go via the proper channels and bring your own manager along for the ride.

The same is also true for those who run a large organization with many layers of management. If you are going directly to the direct reports of your own direct reports about issues that should really involve the person in-between, then you are meddling and it shows disrespect for the person being left out. Could you not delegate this to them? Why not? Could you not coach them to do so?

Being unprofessional

I’m sure that this goes without saying. If you wish to be influential and effective as a manager, then you need to engage with others in a professional manner. This may be in contrast to your exact personality outside of work, but you owe it to all that you interact with to be open, honest, transparent and without motive. You need to operate for the greater good in order to be taken seriously.

Those who are unprofessional erode the trust that the organization has in them, and in higher levels of the org chart where trust is of utmost importance, those who cannot demonstrate it will find themselves unable of moving into these roles.

Going rogue

If you think that the best way to demonstrate how good your idea or initiative is by just doing it without anyone knowing, then it is likely to cause much more conflict down the line than if you had built consensus in the first place. Going rogue is similar to building up technical debt: it gets worse the longer that it continues and it is harder to back out from.

For example, if you thought the best way to make big architectural change in the codebase was to just do it silently rather than taking everyone else along for the ride, then you may find yourself unpopular when those controversial code changes end up being forced through because of an impending deadline for a feature, or even worse, blocking the whole deliverable.

If you are unable to build consensus, then maybe your idea or initiative is not as good as you originally thought it was.

Using politics for personal gain

The last negative area should come as no surprise: you should not use workplace politics for malicious personal gain. Bending ears to force through your recommended candidate so that you get the referral bonus is a terrible thing to do. Using your influence to force others into situations they do not want to be in for your own gain is also abhorrent. Abusing your position to make others feel small, powerless or marginalized is the worst form of politicking and will always catch up with you. Just don’t.

In summary

Workplace politics are very real and when understood and harnessed for the power of good, they give you the ability to move an organization forward in a positive manner. When used poorly or for malicious reasons, you can begin to build a snowball of mistrust that will always come back to bite you, and will limit your career. Engage wisely.