Create Milestones for Your New Job

Leave a reply

People are afraid of taking new jobs. There is a risk of failure of the company you’re joining and potentially of yourself in the role you are accepting. But we all need to accept new jobs at some point. What you should think about is how to cap the downside risk of the two potential situations above. This is indeed possible. I will walk you through my approach.

When you accept a new job, a very healthy practice is to project out the opportunity over a period of time. I like to use increments of six months. What I recommend is you create a document for your job that predicts how the company has evolved, and you yourself have evolved over that time period. This document should ask the following questions:

#1 What should the trajectory of the company be at this time?

This can be represented by numbers, strategic initiatives, funding rounds, whatever makes sense for your mind. Actually, the more the better.

#2 What should my trajectory be at this time?

This can be represented in terms of what you accomplished, what responsibility you accumulated, how much you’re making, what you’ve learned. Again, the more the better.

Okay, so when you join the company, you write this document for let’s say six months, 12 months, and 18 months into the job. When those milestones occur, reflect back on this document and ask the following questions:

#1 Is the company on track?

Predictions are hard, of course, but being on track is great, being ahead of track is awesome, and being off track may be a cause for concern.

#2 Am I on track?

It’s almost as important to ask if your trajectory is on track. Are you learning what you thought you would, accomplishing what you thought you would, making as much as you thought, accumulating the responsibility you hoped for? All of that should be addressed.

If the answer to both of these questions is on track or ahead of track, amazing. You should feel confident continuing to work at the company. If either of these questions is no, however, you need to ask yourself two additional questions.

#1 Can it get back on track?

Let’s say the company is off track. Do you believe in a reasonable plan to get back on track. Was it a one time setback, or are we too far off course to hit the objectives you initially wrote? Similarly for yourself. If only one of the answers above was no, it creates different implications. A fast growing company, but not growing yourself creates a free rider problem for your career. A company where you’re growing yourself, but the company is off target may mean all you’re learning won’t be valued by the market if the company doesn’t end up doing well.

#2 If not, am I comfortable with the new track?

If you’re not on track and don’t feel you can get back on track, you have to ask if you’re comfortable with the new track. This is common. You may have set to high a goal, but things are still objectively going well. That’s fine. You do want to make sure you’re not justifying a mediocre or bad situation because it makes you uncomfortable.

—

If you follow this process, it should let you know if the opportunity you initially thought was worthwhile isn’t there. The key is when you learn this that you don’t continue to stay. If the company and/or yourself on not on track, you don’t expect to get it on track, and you’re not comfortable with the track, you should find a new job. As long as you change jobs when when you reflect every six months and see this, the risk is mitigated. The real risk is staying with a company a long time that is off track for itself and your career, with no way of getting back on, and it’s sacrificing your potential. Those are the only real career mistakes. So, go ahead and take that new job. But use this framework to be honest with yourself about whether it’s working out or not. And if it’s not, find a new one.

Currently listening to Between Two Selves by Octa Octa.

Centralization Vs. Decentralization in Marketplaces and Scaling Companies

Leave a reply

First off, no, this is not a post about blockchain. Sorry to disappoint you. This is a post about structuring your teams, and structuring your business. A common problem I work with entrepreneurs on is where power should be held both inside and outside organizations. These entrepreneurs have heard the stories of how instrumental Uber’s local teams were in their success. They have also heard about marketplaces that have given all of the power to the supply, and also marketplaces where supply has no power. They struggle to understand for their particular business, how much power am I centralizing in HQ, or how much power am I centralizing inside the company vs. outside it.

These issues usually arise in two areas, which particularly, but not exclusively, affect marketplaces. One is around local expansion. When I enter a city or country, who is in charge of that market’s success? Is it a local GM or someone in HQ? The same questions emerge for satellite development offices and going international. Do I hire local managers? Or do people report into managers in HQ? Who owns a country’s growth? The second issue is around who controls the quality of the service. Do we let the supply side determine their level of service, or do we standardize it across all of our supply? Is there value in standardization or variety of service level?

Advice on these topics usually misses the main factors a company should be considering when making these decisions. That main factor is where does the expertise lie, and what enables the best execution. And both of these can change over time. Uber is a great example. Because of training and car inspections, supply side onboarding had to be decentralized to a GM in each market. And because each market needs to boot from scratch, it generally made sense to give the GM responsibility for the entire market. They could do scrappy things to drive supply and demand acquisition and brute force initial liquidity. Once Uber had initial liquidity in these markets though, it ran into decentralization problems. Uber started to build up world class acquisition teams in HQ that didn’t have full control on how to scale customer acquisition. Local teams were still doing scrappy tests that didn’t scale, and not managing budgets as efficiently. Uber eventually centralized a lot of this work, but most people will probably tell you they did it too late, causing a lot of political strife.

On level of service, however, Uber has always strictly standardized their level of service across markets. Uber is not interested in drivers creating their own style of service. Consistency is a key part of Uber’s offering to passengers. Uber decides if they want to introduce varying levels of service in markets in a standardized way, with Black, X, Pool, etc.

At Grubhub, we started with local responsibility for supply with outside salespeople and HQ (read: me) responsible for demand. The playbooks my team developed to drive demand with SEO, SEM, and offline marketing scaled equally well to new markets as long as we reached enough supply. For supply, we had to build knowledge of the local market, and the best way to do that was boots on the ground. Over time, as we refined our process to determine quality restaurant leads and which neighborhoods mattered, we started centralizing supply with an inside sales team in HQ as well. For market launches, we would paratroop salespeople into a market to get to a certain amount of liquidity, then retreat to inside sales to scale.

For level of service, variety matters a lot for a business like Grubhub because not everyone wants to order the same type of food. There is also demand across different price points, time of day, day of week, etc. Variability in the food from restaurant to restaurant is a feature, not a bug. Grubhub uses ratings from the demand side to determine if a restaurant is below a certain floor of quality it is willing to accept, and if it drops below that, they will remove the restaurant from the service. Where Grubhub has standardized more over time is the delivery experience. Grubhub used to outsource 100% of its deliveries to the restaurant, and now over 20% of orders are delivered by Grubhub couriers. I previously explored the variables in the food delivery space here.

Airbnb has evolved similar to Grubhub. At first, Airbnb let hosts define their level of service and encouraged them to express themselves and figure out their own pricing. As Airbnb grew, it developed a deeper understanding of what Airbnb guests want and what prices will be successful. It is now standardizing those pricing levels and amenities hosts are expected to give. Now, they are not booting hosts off the platform who choose not to adopt these strategies. Instead, they are promoting more aggressively the hosts who have specific designations (at first Instant Book and now Airbnb Plus) with higher rankings in search results and special filters. They expect most hosts will conform over time due to these incentives.

It is unclear if this is the right strategy for Airbnb. While baseline expectations for service are a good thing in hospitality, there is a possibility the service could lose some of the uniqueness that partially made it desirable as an alternative to hotels in the first place. Airbnb’s value propositions that made them grow so quickly were lower cost and more unique inventory (both more unique places to stay as well as in more unique locations like local neighborhoods). It will be interesting to see how professionalizing supply works for them in the long term.

Eventbrite is an interesting example of approaching decentralization. Eventbrite works with event creators, commonly known as promoters. What do event promoters know how to do: promote their event! So Eventbrite partially outsourced demand acquisition to its supply of event creators. Event creators knew how to attract ticket buyers better than Eventbrite did in many cases. As Eventbrite has grown though, it has gotten significantly better at helping event creators sell more tickets. It now has proprietary distribution channels the event creators do not have like its app and website, a strong SEO presence, and distribution partnerships.

Eventbrite also has development offices in many different countries now. When you hire a PM for a particular business unit, do they report to the local office leader, who may not have a product background, but knows what is going on in the office really well and knows how to hire locally? Or does the PM report to a product leader that may not even live in the same country but knows how to develop product managers and understands the product strategy? This was a recent problem we worked on. What we decided is that the PM would have a local leader that is in charge of making sure that PM is a happy and productive member of that local office and a functional leader that is in charge of making sure that PM is a happy and productive member of the business unit and product team.

General Best Practices

Out of these examples some best practices emerge. If you’re thinking about these questions for your business, I would ask the following questions:

Am I launching a new market? If so, how much of a replicable playbook do I have on how to launch successfully?

The earlier the stage of the market you are expanding into and the less of a playbook you have for this, the more likely you want a local owner in charge of figuring out how to make the market work. Their job, however, is not to own the market long term. It is to get to liquidity as fast as possible so that subject matter experts in HQ can take over parts of the growth of the market.

If you have a refined playbook like Grubhub eventually did, you may find you don’t need local expertise for supply or demand.

Once a market has launched, who is in charge of the growth of the market?

Once a market has found liquidity, or product/market fit, it depends on how much of what drives that market’s success is shared with the rest of the company. If the market is fairly unique, a GM with control may make sense. However, most markets have a fairly similar growth playbook once the market finds liquidity. Usually, this means, if a GM exists, they should not own the growth of the market. Instead, they control growth levers that cannot be managed effectively from HQ, such as training and local partnerships and local feedback to HQ teams. They also frequently are an execution layer for HQ strategies such a PR, content marketing, etc. A lot of companies make the mistake of keeping the onus of growth on a local person even after it is revealed most of the levers for growth are controlled by HQ, creating a very frustrating role for that GM.

Is supply variability a feature or a bug?

Does the demand side of your marketplace have homogeneous needs? If so, can you standardize that into different products or not? If not, you will allow your supply more control over what services they provide until needs become more homogenized or are cleanly separated into different products that can be standardized.

Who manages local team members?

If they are operations focused on local needs, they are usually best managed by some sort of operational team. At Pinterest, these team members were managed by a Head of International in HQ. At Grubhub, since all of our local people were salespeople, they were managed by a VP of Sales in HQ. If, however, you have local development teams, those teams have different management needs that typically need to be managed by different people. They need a functional manager that can tie them into the HQ’s strategy. Because of the size of the team though, they also need a local manager that can recruit them and make sure they are a happy and effective local employee that an HQ manager won’t have visibility into. As teams scale, they usually add local management layers that report into functional managers in HQ. For product, for example, that might be a Product Lead in a satellite office reporting into a Director or VP of Product in HQ. If you don’t have enough product managers to have a local manager, they usually dually report into the HQ Head of Product and the satellite office manager.

—

Most companies centralize decision-making over time in their main office. They do this not because they are hungry for control, but because they start to build up more expertise than either their local offices or their suppliers. It is not actually the leadership team centralizing the decision-making, but the subject matter experts in HQ. The real question to ask when you are managing these problems yourself is where is the expertise for this problem, and is it changing, and how does execution need to occur for this problem.

An Alternative Approach to Re-Orgs At Your Company

Leave a reply

Re-orgs are an essential part of scaling a team at a company. The organizational structure of the company six months ago may no longer align to the needs of the company or its customers today. While most people would agree with the statement above that insists re-orgs are necessary, everyone hates them. They almost always make some people unhappy, cause employee departures, and stifle productivity both before and after they are executed.

I’ll start with a story of how this works in practice. Grubhub had a fairly stable structure for most of the time I worked there. While it was stable, it certainly wasn’t traditional. While we had crafted large sales, marketing, and customer service teams, we had a very small engineering team for our size and no official product and design teams. The latter two we de facto managed by marketing and a combination of executive leadership. While most companies at the time had a clear product manager role, Grubhub did not. We had product strategy led by marketing and the co-founders, and project managers within engineering that worked with those stakeholders to build effective software. I hired a member of my team to build a loyalty program. This meant that they would do user research, build models that project impact and costs, and work with engineering to launch experiments that would increase frequency of ordering on Grubhub. The person we hired was, in short, awesome. She did a bunch of great research partnering with our UX researcher, built detailed financial models that projected impact, brainstormed many ideas with our designers, and built good rapport with our project managers and engineers when it came time to finally build something.

Around this time, we started discussing as a leadership team if it made sense to start building a product management function for Grubhub. Being privy to those conversations, as I was having my quarterly review with this member of my team, I suggested product management would be a good avenue for her if we create that function, but she would probably need to leave my team to do it. We talked through the details of why I felt that made sense given what she was doing, and she was very open to it.

Fast forward three months, and as I’m on my way to work, I receive an email from my manager the VP Marketing asking to meet when I get in (she always got in super early). When I did, she announced that we were creating a product management function, and that as they thought about what the members of that team should look like, they felt like this member of my team was a perfect model of what a product manager should be at Grubhub. So, effective immediately, they were moving her off my team to be the first consumer product manager. The co-founder of the company was meeting with her when she got in to explain the move, and email would go out right after, and my 1:1 was with her later in the day.

That 1:1 was awkward. While this was ultimately what I wanted for her, and she was nervously happy about it (it’s nice having the co-founder of the company say your behavior is a model of behavior they want at the company), things still felt off. What is supposed to happen to her current projects? What new projects is she picking up? She at one point during the meeting said “oh, you seem sad”. And I wasn’t, just more caught off-guard, and thinking even though we’re making the right decision, are we making it in the right way?

This I find is usually the best case scenario for re-orgs. VPs and C level execs are attuned enough to make the right calls, but execute it top down without director, middle management or IC involvement or feedback on their ideas, leading to a change that is good on paper and may be good in practice too, but seems to strip the team of control. And far more common is the flip side of this scenario: when VPs and C level execs think they know what is good for the people and the team, don’t seek out necessary feedback, and make the wrong call for both the organization and people’s careers who are affected by the re-orgs.

For one of my the companies I advise, going into 2019, for one our business units we knew we likely had to change our organizational structure. Trying not to repeat re-org mistakes, we started working on a structure that would make the re-org act like a feedback-fueled progress driven by the teams instead of by people above them. The first thing we worked on as a leadership team was the objectives for 2019. What did we need to achieve next year to be successful? We then went to the product managers, designers, and engineering managers and explained the objectives. We then tasked them to propose the organizational structure that would help them with these objectives.

They worked directly with their teams to make sure everyone understood the objectives, everyone’s interests and career aspirations, and then they proposed the structure to the leadership team. After this presentation, we worked more to understand the constraints that led to this recommendation, worked through some of those constraints so the team didn’t need to make as many compromises on what they wanted, and then solidified the structure. The product managers, engineering managers, and designers talked through the changes with the rest of the teams, and organically the teams started planning with the new structure in mind. They then set their own team objectives to the align to the business units, as well as their roadmap and key results.

By involving the team members that would be effected from the beginning and making it their decision, we avoided a lot of the awkwardness or bad calls of many re-orgs I have participated in. The teams are happy and working on the new objectives seamlessly. Now, there will certainly be re-orgs that can’t be this inclusive, such as those that involve the transitioning out of an executive, or with teams that would not be capable of tying the objectives to an effective team structure. The former will never be seamless when people’s managers leave. The latter indicates a separate problem of lack of team responsibility that needs to be addressed first. But if you are not facing one of these scenarios, here are some things I have learned you may want to incorporate into your next re-org.

  1. Start with making sure the objectives of the company/team/business unit, etc. are clear, and that the executive team is aligned on them.
  2. Inform the teams affected that the new objectives create an opportunity for them to re-organize to be more effective at achieving these objectives.
  3. Empower the teams to propose a new structure that would better allow them to achieve the objectives
  4. When these teams present their proposals, make sure they focus on talking through the constraints that led to their proposal. These are frequently resourcing e.g. not enough Android engineers, cross-department collaboration or lack thereof e.g. no SRE support next quarter, technical or design debt, et al., They can be relationship based or based on location for distributed teams.
  5. Resist the urge to edit the choices directly as a leadership team. Instead, focusing on editing their constraints.

The Problems With Martech, and Why Martech is Actually for Engineers

Leave a reply

Since I spent some time in VC land and have a background in marketing, a lot of people ask me about martech, or technology built for the marketers. Are these good businesses? Which tools should they use/are on the rise?

In short, I hate martech, and think martech will decline as a category, and most martech businesses will not be very successful. I think there are a few reasons for this that are not well understood, but if you understand them, it can unlock some martech opportunities that are still quite large for entrepreneurs, and help marketers understand which technologies to bet on vs. bring in house. The main misunderstanding is that successful martech is actually for engineers, not marketers. Let’s talk about why that’s the case.

Martech is a Response to Engineering Constraints
A controversial opinion I have stated before is that the marketing function in technology companies is usually a response to engineering constraints. If you don’t have enough engineers to build a system to manage bidding for performance marketing, you hire a marketer. If you don’t have engineers that can work on SEO, you hire a marketer. If you can’t build a great email system, you hire a marketer. Most key marketing roles are manual tasks that can better be solved with engineering. The smartest marketers, realizing this, started automating a lot of their work through third party tools, and if they could, even better, first party tools. This is how martech exploded over the last decade. Marketers actually had important, if not critically under-weighted, responsibilities for the company. For example, I was in charge of getting new people to try ordering online at Grubhub, and to keep them coming back once they did. My team used a lot of martech tools to do that.

Engineering Constraints Are Being Laxed
While hiring engineers inside companies to solve these problems is still extremely competitive, engineering constraints are (slowly) being laxed across every technology company I meet. Startups and technology companies today have many more engineers working on more functions (due to improvements on engineering technology) than we had at Grubhub during similar stages of our company.

These engineering constraints being laxed means martech companies have to compete with the engineers at the company for the best way to solve a marketing problem. And besides there being more engineers in a company to work on these problems, engineers are now more likely to want to work on these problems or reject these tools as best practices. Growth teams have emerged to work on a lot of the traditional marketing problems marketing teams bought software for: email, SEO, landing page optimization, onboarding, etc.

Martech now finds itself in a more competitive environment since “build” in the “build or buy” equation is more likely than it used to be. Also, if engineers inside a company do decide to build instead of buy a solution, a lot of times what they build is more effective than what the martech provider can offer. This is not to say engineers inside tech companies are better than engineers inside martech companies; engineers inside tech companies simply have unfair advantages. Not only can engineers building the solution for their company build directly to the needs of their company instead of adapt some generic solution; they can also more easily integrate with the data needed for these tools to make the right decisions. It is notoriously difficult, for example, for many martech tools to integrate conversion data, and certainly much harder for lifetime value data. This is much more easily done with an in-house built tool.

Platforms Also Limit Martech’s Reach
Martech companies face the squeeze from the other side of the integration as well. Usually, martech companies integrate into some other system: advertising companies like Google and Facebook, adtech companies like exchanges and demand side platforms, email service providers and email clients, etc. What happened is these martech companies built value added features on top of a platform to deliver extra value to customers. What is happening now is those platforms are either integrating those best features themselves, so you don’t need the martech company for it anymore, or deleting the access that enables it, because the platform doesn’t actually want that level of transparency.

Where Can Martech Be Successful?
So these companies have the platforms stealing their features or cutting off the access that makes them possible on one side, and engineers at the companies of their clients building deeper integrations themselves. So, if most martech solutions have a disadvantage to competing with in-house engineering solutions, or the platforms starts competing with them, what type of martech tools have an advantage?

Option 1: Leverage Data Network Effects
One key example where martech thrives is when the external data becomes more important than the internal data. If a martech tool can be gathering data from multiple companies, and create a data network effect from this aggregation, thereby helping all companies improve in a way they could not on their own, they are very defensible. Sift Science is a great example of this. By being used as a fraud provider across thousands of companies, they have data any individual company won’t have in determining if a transaction is fraudulent or not.

Option 2: Manage Pain
Similarly, integrations with a bunch of key operators or vendors are very defensible in martech. Litmus is a classic example historically. Email providers have notoriously finicky rules around what renders in their systems and how, and they are not very transparent. Engineers and designers hate coding for email, and it’s hard for them to remember all the rules for all the different types of email clients. Litmus allowed you to preview what your emails looked like across all major clients to spot errors before you send the email, and generally became an all-encompassing email QA tool. No engineer internally wants to build that, and they will never be as good as Litmus at doing it because Litmus has been doing it for billions of emails, so it has seen many more cases, and has better integrations with email providers. Another example of removing engineering pain is Heap Analytics, which auto-tags events, removing one of the most painful parts of setting up a new analytics vendor.

Option 3: Leverage Cross Side Network Effects
A more modern example is the customer data platform companies Segment and mParticle. These companies integrate with hundreds of other companies marketers use for various purposes: web analytics, conversion tracking for performance marketing, crash reporting, et al. Integrating these companies saves engineers time because they integrate once, and any other solutions they need can now be enabled instantly. These integrations not only help marketing, but product, and engineering as well. These companies have created a cross side network effect between customers and other technology providers. Data platform companies are hard to rip out once you integrate because they are so integrated in all of your processes.

The Real Answer: Change the Target Customer
Okay, so all of these are great options, but they actually share one thing in common: they have really shifted the target customer to the engineer instead of the marketer. Sure, the marketer may be the person requesting the solution, but the solution is chosen because the engineers like it. Many things an engineer has to do are painful, and as much as engineers like to solve their own problems, if you show value to them, they will appreciate it. So I am very bullish on engtech companies masquerading as martech. Other examples of this besides the ones above are data visualization platforms like Mode and Periscope.

Bonus Option: Pick the Right Marketing Customer
One other strategy that is very successful for martech companies is to build targeted solutions for the types of companies where marketing is more central to the organization’s success. While marketing is ebbing in importance in most tech companies, one area it is thriving is in ecommerce companies, whose main playbooks are logistical on product delivery, and where brand + performance marketing drive all sales. The product is something delivered offline, so the product and engineering teams are more subservient to marketing than in other functions, and because the product is delivered offline, these teams usually have less engineers than other companies. Narvar is a great example for ecommerce tracking. Buffer is a great example for social media marketing. Canva is a great tool to help design creative for marketing campaigns and social media posts.

—

Martech is a very challenging space for an entrepreneur. If you are going to tackle it, there are distinct strategies like data network effects, pain management and maintenance, and cross side network effects that make it more possible to build a sustainable business. Approaching the right customers, either in role (engineering) or space (ecommerce) also make the road easier.  If you have any other tips on building a great martech business, feel free to leave them in the comments.

Currently listening to Slide by George Clanton.

Q&A with Elena Verna at Amplitude Amplify Conference

Leave a reply

I recently gave a presentation at the Amplitude Amplify Conference on Growth Models. I then had the pleasure of interviewing one of my favorite leaders, Elena Verna, GM of the Consumer Business at MalwareBytes and previous SVP of Growth at SurveyMonkey. The video is now online. We talk about how MalwareBytes and SurveyMonkey grow, the different types of word of mouth, how to think about freemium as a strategy, the content loops of SurveyMonkey and Eventbrite, building network effects, and much more.

Announcing the next Retention Deep Dive, Growth Series, and something new

Leave a reply

Over the last few years, I’ve worked with Brian Balfour (CEO Reforge, formerly VP Growth @ HubSpot) as a Growth mentor and contributor to the Reforge programs. These are part-time programs (no need to take time off work) specifically designed for experienced Product Managers, Marketers, Engineers, and UX/Designers in both B2B and B2C companies.

Today, Reforge announced their three upcoming programs this fall:

1) The Retention + Engagement Deep Dive program. I worked closely with Brian developing this program, which looks at every aspect of retention including activation, engagement, resurrection, and churn.

2) The Growth Models Deep Dive program. This is a new, detailed examination of a key growth topic Brian and I developed this year with Kevin Kwok.

3) The Growth Series program. This is Reforge’s flagship program that provides an overview of the key topics in growth that’s been 100% revamped to reflect today’s growth challenges.

Apply to Reforge (Takes ~5 minutes)

Each Reforge program runs from September 24th through November 16th. Seats always fill up fast, and I’m excited to be involved. I’ll also be doing some speaking and Q&A during the events.

Besides Brian, Kevin and myself, other hosts include Andrew Chen (General Partner @ Andreessen Horowitz), Shaun Clowes (VP Growth @ Metromile, former Head of Growth @ Atlassian), Dan Hockenmaier (former Director of Growth @ Thumbtack), Heidi Gibson (Sr. Director of Product Management @ GoDaddy), and Yuriy Timen (Head of Growth @ Grammarly).

About the Reforge Programs
These are all invite-only, part-time programs that last 8 weeks. Each program requires a time commitment of 4 – 8 hours per week. They’re designed for Product Managers, Marketers, Engineers, and UX/Designers in both B2B and B2C companies looking to accelerate growth in their companies and in their careers by developing a systematic approach to thinking about, acting on, and solving growth problems.

In addition to the course material, we’ll also hear from leaders in the industry through interviews, live talks, and workshops, including:

Fareed Mosavat, Growth @ Slack
Ken Rudin, Head of Growth, Search @ Google
Brian Rothenberg, VP Growth and Marketing @ Eventbrite
Ravi Mehta, Product Director @ Facebook
Mike Duboe, Head of Growth @ Stitch Fix
Josh Lu, Sr. Director, PM @ Zynga
Guillaume Cabane, VP Growth @ Drift
Matt Plotke, Head of Growth @ Stripe
Joanna Lord, CMO @ ClassPass
Gina Gotthilf, ex-Growth Lead @ Duolingo
Elena Verna, SVP Growth @ MalwareBytes
Kieran Flanagan, VP Growth/Marketing @ HubSpot
Naomi Pilosof Ionita, Partner @ Menlo Ventures
Nick Soman, ex-Growth Product Lead @ Gusto
Nate Moch, VP Growth @ Zillow
Simon Tisminezky, Head of Growth @ Ipsy
Steve Dupree, Former VP Marketing @ SoFi
See the full list here

Here’s some more detail about each program below:

About the Retention + Engagement Deep Dive
Retention + Engagement Deep Dive zooms in on one of the most important sub-topics of growth.

Retention and engagement separates those companies in the top 1% of their category. Every improvement in retention improves acquisition, monetization, and virality. But moving the needle on retention is hard.

This program takes a microscope to every aspect of retention, including:

  • Properly define, measure, segment, and analyze your retention
  • Find and quantify the three moments every new user goes through to create a long-term retained user
  • Construct a high performing activation flow from the ground up using detailed strategies across product, notifications, incentives, and more
  • Layer your engagement strategies to build a compounding growth machine at your company
  • Articulating retention and engagement initiatives across teams, as well as influencing how leaders think about retention in your company
  • Walk step-by-step through of lessons applied to dozens of examples from companies like Instagram, Zoom, Spotify, Everlane, Airbnb, Turbotax, Jira, Credit Karma, Blue Bottle
  • And more…

The Retention + Engagement Deep Dive is designed for growth professionals who are looking to zoom in on retention, either because their job is focused on retention, or because they already have an advanced working understanding of the quant and qual fundamentals of growth and are looking to build additional competency in retention and engagement.

Apply for the Retention + Engagement Deep Dive

About the Growth Models Deep Dive
The new Growth Models Deep Dive addresses an essential new skill and topic that every growth practitioner needs to understand. Your growth model is the essential tool that drives alignment, prioritization, strategic investments, metrics, and ultimately, growth. Without it, your team ends up setting faulty goals, focusing on sub-optimal initiatives, and running in opposite directions.

This program goes deep into growth models across companies. You will:

  • Learn how the fastest growing products actually grow (hint: the answer isn’t funnels)
  • Dissect how the fastest growing products like Uber, Slack, Dropbox, Stripe, Airtable, Instagram, Fortnite, Tinder, and others grow using growth loops
  • Learn the detailed components of 20+ growth loops
  • Systematically construct growth loops your product can use after analyzing the three qualitative properties of every growth loop
  • Assess gaps and uncover opportunities for growth by identifying, measuring, and analyzing your products existing growth loops
  • Complete a step-by-step walkthrough to build your quantitative model for a single loop and your entire product
  • Communicate actionable insights from your growth model to obtain buy-in from leadership and across teams
  • And more…

The Growth Models Deep Dive is designed for growth professionals looking to focus on growth modeling, either because their job requires modeling their company or product’s growth or because they’re in a leadership role. It’s especially useful for growth leaders looking to influence leadership, set a team’s direction, and rally colleagues using growth models.

Apply for the Growth Models Deep Dive

About the Growth Series
The Growth Series is a comprehensive overview of the key topics in growth. The program is designed to help you accelerate growth of your product, company and your career by creating a prioritized list of retention strategies, building your quantitative growth model, and much more. Plus, the Reforge team spent +100 hours collecting feedback, investigating new growth concepts with experts, and analyzing the latest strategies coming out of top companies to completely overhaul the content with new topics, frameworks, and relevant examples.

During the Growth Series, you’ll learn:

  • Going from understanding one or two pieces of your growth model to understanding how the entire system works together
  • Evaluating the key components of growth (acquisition, retention, monetization) and how they feed one another
  • How to construct a holistic growth model, bringing together all the components of the funnel
  • How to understand and evaluate the user motivations behind the levers in your growth model
  • Running a continual, self-reinforcing experimentation process to execute against your growth model and user psychology
  • Learn how to properly call, dissect, and analyze an experiment, plus implement the results across your team
  • And more…

The Growth Series is designed for practitioners who already know the basics of growth and are figuring out how to take the next step. Participants are assumed to have knowledge about A/B testing, ad buying, and other fundamental tactics, and are ready to take on the bigger challenge of thinking about the entire picture of growth and forming a coherent and compelling strategy.

Apply to the Growth Series

The Life and Death of Product Marketing

Leave a reply

This is part two in likely a three part series on career paths. You can read about the analyst career path here.

As someone who majored in marketing in undergrad and has an MBA with a concentration in marketing, I receive a lot of career advice requests from up and coming marketers. My feedback is usually a wake up call and not very pleasant. Marketing, especially in a technology company, has been suffering a death from a thousand cuts for years now. There are a few reasons for this. As I blogged about before, marketing’s definition grew too broad for one area to be an effective owner. An area I haven’t talked about before is how many roles in marketing are largely a response to engineering constraints. And with computer science grads multiplying like rabbits years after year, those engineering constraints are starting to relax a bit. I’ll analyze some roles in particular who I think are the most affected by this over the next five to ten years. I’ll start with product marketing.

Product marketing has suffered from an identity crisis as long as I have known the term. Product marketing, when done correctly (which rarely happens), is usually in charge of three things:

  • Deciding a soon to be released product’s positioning and messaging
  • Launching the product and making sure users (in B2C) or customers and salespeople (in B2B) understand its value
  • Drive demand and usage of the product

What that means in practice is that with well oiled product marketing teams, they owned the relationship with the consumer or customer and the outlets for how to reach them. This meant they talked to customers one on one and ran surveys. They managed email outreach, press strategy, potentially even an ad budget.

As you look at these responsibilities, it gets easy to see how this definition falls apart in many companies. For one, many companies don’t launch that many new products or features each year. Teams now have copywriters that integrate with product teams to test messaging iteratively.

Launching a feature is about that feature’s journey for feature/product fit, which means it rolls out in small experiments instead of a big press push. A press push would only be justified if the feature is successful in its experiments. A feature launch’s importance is inversely correlated to the number of users it is intended to reach and only weakly correlated to market power, which is why product marketing has always been more effective at B2B companies, and large ones at that.

Product teams now are more likely to be staffed with user researchers who specialize in gleaning insights from users and customers, and may even dedicated quantitative researchers as well for survey design. Pinterest had both, for example. Even if these are not staffed, as product managers have shifted from executional roles to strategic ones over time, they frequently see understanding the user or customer as their responsibility. Designers on product teams frequently feel the same.

Lastly, when thinking about driving demand and usage, that again is something product teams should only care about once they know the feature is driving value. At that point, ever more prevalent growth teams in charge of overall product growth decide how to use growth of that feature as tool to overall product growth. These are cross-functional teams between design, product, analytics, and engineering, and only sometimes include marketers.

The jack of all trades design of the product marketer role is being attacked on all sides as teams determine how to more effectively reach their users or customers and build things they will use. I don’t see these trends as a failure of the product marketing function. In many ways, it’s the opposite. You should always be trying to obsolete your role in a company. All of these responsibilities product marketing owned now being prioritized or specialized in by other functions shows that organizations now understand the marketing of their own products is important and can’t be outsourced at the end of development.

That said, this transition does leave current product marketers in an untenuous position, and many have been asking me what they should do. I see three opportunities that are available for product marketers.

Option 1: Migrate into Product Management
Product marketers build relationships with product teams already. They should start to leverage this for opportunities to work on product management projects, not just to launch them, but to actually work with engineers and designers to build them. These projects are fairly easy to find as product managers are always strapped for time. Once a product marketer does a few projects successfully, I have found their migration to full-time product manager happen pretty seamlessly at multiple companies. Anecdotally, product marketers tend to become very successful product managers because they focus on understanding users and are great at framing the products they build for user value and having users understand that value.

Option 2: Migrate into User Research
Companies are always looking for more user researchers, and they are product managers’ and designers’ best friends. Product marketers already excel at talking to users. The migration here is more about the in between of product marketers focused historically. Instead of soliciting ideas and selling solutions, user researchers receive feedback on potential solutions in process or problems with the current product by watching current product use. There are dedicated programs where you can learn the tools of the trade for user research, and some companies are training people in user research internally because they are so short-staffed. Even if the latter is not available, approaching user research leaders and asking about opportunities to break into their team are usually welcome, and can start, like with product management, on some distinct projects before migrating full time.

Option 3: Move into Dedicated Brand Role
As companies grow larger, they build dedicated brand teams that tackle perception problems, spend ad dollars to use brand marketing to drive long term growth, and adjust company level positioning over time. Product marketers are used to driving positioning of individual features of products, and with that already have a good understanding of overall company positioning. This may or may not be an option depending on the specific needs of the company at the time. Usually, the larger the company, the more likely this opportunity exists.

—
The future of the product marketing role is fraught with uncertainty. In B2B companies, the role is definitely better established and positioned for success, but I think it’s only a matter of time before those roles face the same challenges consumer product marketers face today around specialization and new team structures that gradually phase this role out. If you are in product marketing, don’t panic. Just think strategically about how to position yourself for one of the three above options to maintain career growth.

The Analyst Career Path

1 Reply

I’ve written before about analytics teams as a crucial function in today’s technology companies. Technology companies are rapidly hiring analyst roles to pair with their product teams. And while my previous post discussed how to hire analysts and structure their teams within organizations, I haven’t written about how analysts should approach their careers.

Many technology roles, at startups in particular, have an issue with career progression. While established industries have defined career ladders, the path of career advancement is much less clear in many technology roles. Engineering, being the largest and oldest function in technology companies, now has a well defined individual contributor and manager career path all the way up to VP Engineering and CTO. Product Managers know they can progress to manager roles at their companies all the way to VP Product, and if they want to remain and individual contributor, they can still grow by working on more and more complex and strategic products over time. As I’ve talked to many analysts and analytics teams, this progression is not as well defined. I will outline how I think about this progression as someone who has been an analyst and managed analysts.

Option 1: Graduate into Data Science

If someone wants to remain an individual contributor and not manage, at some point the only way to become a better analyst is to graduate into a data science role. Now, there is some confusion with where the line is between analyst and data scientist, and many companies just call all of their analysts data science as a form of title inflation. I define the role of an analyst as someone who uses data to help identify and communicate business opportunities, and drive decisions for teams. This includes targeted analysis driven by others as well as free form analysis driven the analyst. From a process perspective, this includes everything from making recommendations, helping with experimentation, and creating dashboards to help others make decisions. From a tooling perspective, this means everything from writing SQL queries, identifying logging opportunities for product engineering and database design opportunities with data engineering, creating new dashboards and visualizations. An analyst retrieves, analyzes, and recommends, and is judged by not only how good those recommendations are, but how often they are followed.

So, how does data science differ? A data scientist writes code beyond SQL to manipulate data for analysis and potentially for product experience. A data scientist can write an algorithm that powers a personalized experience in the product, or just do more complicated analyses requiring more sophisticated querying using Python, R, etc. Data scientists jump in when analyses are too complicated to be handled by analysts, and also frequently partner or embed with product and engineering teams to change the product. This is more than just a higher-power analyst role though. Data scientists have deep expertise in certain areas, like machine learning, statistical inference, and focus on solving specific, hard problems over longer time horizons.

Option 2: Become an Analytics Manager
If you wish to get on a management track, becoming an analytics manager is the natural path. Since analysts are being hired so frequently, they need managers who can mentor and coordinate learnings between teams. While analysts are best embedded, analytics management bears the important responsibility of solving company-wide analytics issues related to tooling, process, etc.

Option 3: Graduate into Product Management
The third path that analysts can choose to grow their career is migrate into product management. Technically, product managers and analysts are peers in cross-functional teams, but product management has better career pathing that doesn’t require as much technical investment as data science, and product managers tend to have a bit more power in organizations today.

The migration of analysts to product manager is increasingly common as more and more product teams rely on data as the foundation for most decision-making. This has certainly been most true on growth teams and teams that utilize personalization, but I believe all future product teams are data savvy. A significant percentage of product managers at Pinterest started as analysts at the company. This same migration is also true for marketing analysts. They tend to become quantitative marketers over time, or switch to product analytics.

—
Being successful as an analyst is peculiar is that it almost requires a switch in roles over the time in ways that are not true for design, engineering, and many other roles in technology companies. Fortunately, the analyst has a lot of choices on how to progress within an organization. Hopefully, managers of analysts get better at outlining these different opportunities and help analysts position themselves toward the best ones for them over time.

Thanks to George Xing for reading early drafts of this.

Currently listening to Compro by Skee Mask.

The Autonomy Spectrum: How Much Autonomy Should You Give Your Teams?

Leave a reply

Many people are familiar with Dan Pink’s work in Drive that to be the most productive, happy at work, etc., you need to have autonomy, mastery, and purpose. While a lot has been written about how to create purpose inside companies and crafting compelling missions, I would like to spend some time to dig into the details on autonomy. As founders and senior leaders of companies, it can be tough to understand how to give autonomy to employees and also drive toward a singular vision and commit to things that need to happen for other components of the business to work. I have found creating a spectrum of autonomy is helpful, and discussing with senior leadership and your team where you are on that spectrum.

How do you create an autonomy spectrum for your team or company? It’s helpful to start at the extremes. On one end of the spectrum, you would tell your team exactly what to do and how to do it. This is a complete lack of autonomy. On another end of the spectrum, employees have free reign to work on whatever they would like to work on. These projects may have nothing to do with the business, or could be completely aligned. That represents 100% autonomy.

Usually, people agree that neither extreme is particularly helpful. So how do you decide where in between your company or team should be? I like to work backward from 0% autonomy, and see where leaders start to get less comfortable. Let’s take an example recently from my time working with one of the companies I advise. The CEO asked me to come in and help the leadership team think through an expansion of their product. So that is step 1 of the autonomy spectrum, handing a business opportunity to the team from the CEO.

CEO: We have this opportunity for expansion (Business Opportunity)

Working down from that requirement, one executive volunteered to lead this initiative and did a bunch of research on the expansion opportunity. She talked to potential customers of the expansion, validated the pain points of this segment, and discovered a need the company could solve. So, she started settling around a vision of a new product experience leveraging the company’s existing strengths and identifying what new strengths needed to be built.

Executive: The way to attack this opportunity is to solve this specific problem for this segment (Persona and Product Vision)

The team she managed built an MVP attempting to solve this problem, and measured a lot of early usage and did qualitative research on what they had built. At this point, I stepped in to temporarily lead the product team and saw specific issues from the data and the research around the breadth of the solution, the quality of the options we provided, and the value of our solution vs. existing competitors in the market.

VP Product: Solve these four problems with the event discovery app (Problem Scope)

I also saw a team whose operating cadence matched a mature product with clear requirements rather than a fast moving team that uses research and experiments to find product-market fit. So, I created a new process that would structure them better for the problems they were facing and give them more autonomy.

At this point, we worked as a team to organize all of the product teams to work on these problems. As a leadership team, we chose not to identify solutions to these problems, but to put the product teams in charge of determining their own potential solutions. We created a weekly time where our persona would be in the building to provide feedback to our work. We also created a weekly meeting to review research feedback and experiment results.

VP Product: Test ideas with our target persona and run experiments targeting these problems (Process)

This is where we chose to sit on the autonomy spectrum. Prioritize business opportunity, vision, scope, and some process. Create autonomy for the team to define solutions and deeper process on how they want to get there. There are of course other options here. We could have chosen to prioritize ideas the teams invent to solve these problems, even come up with the solutions or how they would validate with research and experiments. There is no clear cut place to draw the line where you start thinking this way.

What is more important is to try to move the line to the left over time. When I advise leadership teams, I tell them that their goal should be to push decision-making as far down the org chart as possible. For leaders that have historically erred on the side of low autonomy, they need to understand how far they can start to push decision-making down without creating chaos. After all, Pink says that mastery is about providing stretch assignments, but not assignments employees cannot possibly be successful in. This process usually starts by moving to one additional layer of autonomy than normal and measuring results. If that is successful, leaders can be confident moving to another additional layer of autonomy. If this is not successful, then leadership needs to think about what type of training it needs to build so that this is possible in the future. I foresee a future at this company where the teams are in charge of prioritizing the problems as well as the solutions because they will be the experts from talking to our persona every week.

This is how Pinterest operated. Product teams created their own missions and problems they wanted to solve, and they were approved by the leadership team. Every six months, teams updated their OKRs to define the new problems they wanted to target and how they would measure success. No company starts there. Especially with startups, founders are used to setting the vision as well as coming up with product ideas. But as companies scale, leaders have to defer decision-making more so they can continue to move fast. The founders cannot be in every meeting nor can they be the experts on every topic.

—
Autonomy is a difficult topic to grasp inside a company. No CEO or senior leader wants to hand over the reigns to every decision to a team of varying levels of experience and confidence, but trying to make every decision stifles creativity and limits execution pace. Use the autonomy spectrum to build a honest understanding of where the company or teams you manage are and where you would like it to be over time. When you’re confident you are in the right place, communicate this spectrum and why you have made the decisions you’ve made on the level of autonomy you’re comfortable with. Employees will have a much clearer understanding of their role and can build better mastery and purpose as a result.