Allison Pickens' Podcast

VCs have been sounding the alarms, and everyone is wondering how to conserve cash. What decisions should you make in your go-to-market?

I explored these questions with Alexa Grabell, CEO & Founder of Pocus, who just announced her Series A from Coatue (and me!). We discussed topics such as:

* What initiatives should you prioritize across your GTM?

* How do you run a category creation / community motion in a low-cost way?

* What do you do if you’ve already hired senior (i.e. highly paid) GTM leaders?

I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and other B2B businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about:

* LaunchNotes: Director of Engineering

* Kingdom Supercultures: Head of People

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* Guide: Head of Marketing

Transcript

Allison: Alexa, thank you so much for joining us today. You and I have done a fair bit of content together in the past, and every time we find new topics to explore. So I'm really excited to have you back today.

Alexa: Thank you for having me, Allison. I love that we're both tuning in from Philadelphia right now [where we both grew up and where our extended families live].

Allison: Representing Philly! So today we're going to talk about, what do current market conditions mean for a company's go to market strategy, which is obviously a topic that's on many people's minds right now. I think you're going to have some very interesting insights into this. To start, can you just talk broadly about how would a potential recession impact go to market teams?

Alexa: Yeah, it's a great question. Stepping back a bit, maybe I can talk about my background, because then I think the thought process around product led growth and product led sales can inform how I think about the recession and those in the community that I've been communicating with recently.

Quickly, I'm the founder of Pocus, which is a product-led sales platform. We help sales and go-to-market teams at product-led-growth companies understand their data, to convert it into revenue. With a recession potentially coming soon, people are asking, What do we do about our go to market? If we are PLG, do we convert to sales led or vice versa? Should I be thinking about hybrid?

If I were to separate this into four different areas of impact for what go to market looks like, I would say there's an impact on leadership — leaders are saying, we need to take a hard look at our go to market metrics. We need to look at cost of customer acquisition, net dollar retention, revenue, what is the true health of the business? And we're moving from a time where it was about, “let's throw money and experiment and just grow as fast as we can” to “okay, let's be very thoughtful and have durable growth and profitability.”

The second area of impact would be sales team. There's been unfortunately a lot of chat about layoffs. It's taking over my LinkedIn right now. Companies are starting to think, if I have only a sales led motion, that means that the number of heads I have are directly correlated to revenue. But people want to get creative.

Third would be marketing teams. I think obviously there's going to be less budget for paid ads, marketing, and so folks will have to get really creative with organic channels — such as content and community.

Then finally, buyers. It’s going to be a tougher sell to get the money to actually make the purchase. They're going to have to see the value before that.

Allison: It seems pretty clear that if you pursue a product like growth strategy, probably you are going to be able to grow more efficiently. I think that's probably how most people think about PLG. Does that mean that if I'm not a PLG company, I should think about shifting into PLG?

Alexa: Definitely wouldn't say that's the rule. It depends. It could be the answer. It could not be. So I'm not saying that if you have a really strong sales led motion, it's time to flip the switch and just make a huge pivot and become product led.

Product led growth companies are saying, how do I remove any friction in the onboarding process? How do I activate customers? How do I reduce the need for humans in this process, so that buyers can realize the value without chatting with humans throughout the process?

If I were a sales-led company, maybe you do have the budget to experiment with freemium or free trial. Great. But my advice would be, put on your PLG thinking cap and think about, where can I eliminate friction and add product earlier in the user journey? I don't care if you call it product led growth. Just think about removing friction.

For example, I was just chatting with the CEO of really fast growing company. They're at the series D stage, and they have hypergrowth via a sales-led motion. And what we were talking about is, where is the lowest hanging fruit, where can he drive folks to the product, reduce friction, make things more automated. And we talked about the onboarding process. So after a free trial, what happens for them is they have a sales rep reach out and say, "Okay, your free trial is coming to an end. Do you want to chat about what the relationship can look like? Then I'll send you an invoice." That process — and I was actually on the receiving end of that process at one point — is for most of your customers, not necessary. If you have an SMB or mid-market customer, that could have been eliminated by just saying, "Swipe your credit card after the free trial," and have a sales assist person or product specialist reach out and say, "I'm here for you." And then maybe 10% of the customers that are more enterprise can have that call.

So look at those areas where you can take a step back and say, do we really need a human there? Or can this process be automated? If we don't need a human there, what's a better use of that person's time? And in my opinion, a better use of that person's time, instead of hopping on a 30-minute call with everyone who doesn't need to, is reaching out and saying, how can I help you? How can I add more value? And building that relationship.

Allison: If I am a more traditional sales-led company, and I'm looking to experiment with more of a hybrid model where I have some of these best practices of product led growth baked into my model of the future, what might be some experiments that I could run in order to adopt some PLG practices?

Alexa: Yeah, product led growth is just a series of hypotheses and experiments to test. So if you are lucky that you have some product touch points before the buying cycle, whether that is a free trial or a freemium product, instead of reaching out to every single customer that's on a free trial, an experiment you can run is to say, "We're going to take this subset of customers and see how much longer it takes them to convert from free to paid without a human touchpoint. And then how much does the human touchpoint actually pull forward the revenue?"

If the human touchpoint of a sales rep reaching out and getting on the phone, doing discovery and sending an invoice cuts down the sales cycle from, say, six months to six days, that's absolutely worth it to still have that. But what I would guess is in a lot of companies with a strong free trial and strong product led motion, where the product's really self explanatory and you can do a lot of creative things like email templates for onboarding and in-app onboarding experiments, then what you'll see is what's the difference between one month and two months? Does that actually matter? Or is that pulling your revenue forward just a month, is that worth it for that sales rep?

And are there other creative things we can do within the product — adding a Chrome extension, adding nudges, or adding a Drift campaign — that don't involve a sales person, but can actually bring revenue forward by that same amount?

It's a bunch of baby steps and experiments along the way to figure out what is possible for our organization, and how those changes impact the long term revenue numbers.

Allison: Let's say I'm already a product led sales company and, therefore, I'm probably doing things quite efficiently already. What should I do, given the potential recession, to protect my PLG motion?

Alexa: If you already have a product led sales motion, what that tells me is you are pretty data driven. You are tapping into your self serve existing users and trying to convert from a free trial to paid, or to find upsell and cross-sell opportunities.

The more that you can be data driven and use that data that's usually in places like your data warehouse to supercharge your go to market team, the more you're going to be able to close deals faster. And so what I actually mean by that is, there’s a lot of data that lives across your organization, around how your users are using your product: who's signing up, who's engaging with what features, are they sharing the product? Typically, that data lives in a data warehouse like Snowflake or Redshift or BigQuery.

The more that you can get sales teams and customer success teams access to that data, the better. For example, if you are an SDR, and you want the highest rate of getting on a call and finding a qualified opportunity, would you rather go after someone who's been on your product for six months and clearly loves the product and has shared it with many other folks? Or would you rather cold DM someone on LinkedIn? Statistically, the first option is better. So how do you find that data about who the good customer is? That's what's typically trapped in the data warehouse. So the more that companies can supercharge and give SDRs access to the data and let them analyze it and take action on it, the better.

This goes for various roles. So account managers — if they want to understand which of their accounts has an opportunity for upsell or cross-sell or expansion, instead of having several different discovery calls to figure out what teams might have an opportunity there to start using your product, or where you think that your existing users could benefit from a new module or a new product feature, look in your data. That can save you a ton of time in talking to the customers. I'm not saying you shouldn't talk to them, but you should be able to go into those conversations and say, "Hey, I noticed you're doing X, but not Y. Can I help you with Y?" Be as data driven as possible to customize the message to speed up that sales cycle.

Allison: Now, if I'm a PLS company, product led sales company, and I'm constrained in headcount, budget, or recruiting capacity, what roles should I prioritize across my go to market motion?

Alexa: It's a really good question, and it is different for every company. If you're really focused on new business, maybe you want to bring in some AEs. If you're focused on expanding existing relationships, maybe it's more in the customer success side.

In this market, it’s obviously going to be less expensive to expand existing customers versus find new business. And it's going to be more expensive to lose existing customers than to lose someone who was never a customer. How do I retain these existing customers and make them continuously happy, paying, and activated on our product? You would want to look at more of the post-sales roles or folks that can drive adoption, activation, and eventually renewal, upsell, and expansion.

If you have, for example, a bunch of self-serve users, and you are saying, how do I then convert those to paid, I would look at sales assist, product specialists, or onboarding specialists — these are all hybrid roles of SDR, support, and success. They’ll help users get the most value out of the product quicker, so that they convert to paid. Or if you are having trouble with expansion and renewals, then you could leverage a one-to-many CSM or digital scaled CSM group.

Look at your organization, figure out how to grow your business with the existing user base, and then find the areas of friction and where you need humans to be involved.

Allison: I know that you and your company have been amazing at building community, partly in service of category creation. I know a lot of companies are trying to pursue a category creation motion. That can be very expensive, which is obviously not a desirable thing in any case, but also particularly entering a potential downturn. So if I'm trying to be a category creator, I'm trying to build community around my ideas and my company, what's a low-cost way to do that?

Alexa: First, you should consider, do I need to create a new category? And do I want to put the resources toward this? Because like you said, it can be very expensive. It's a lot of work. So you need to only do it if you know the category doesn't already exist, and this is part of your long term strategy. This isn't just something to experiment with for the year. It's part of the entire growth of your organization.

You and I talked about this for a long time in several meetings, around why there needs to be this product led sales category. For us, particularly, it just didn't exist. It's a new sales motion, new type of role, new tech stack. And so we were very confident that this had to happen, and we felt a pull of the community with that.

I know that the experts all say category creation is expensive, but I think marketing in general is expensive. It's more a reallocation of where you want to spend your budget.

So for us, we built the Pocus community. We started this time last year with 20 people on a Slack channel, and our whole goal was quality over quantity — to add a lot of value, get experts in the room that are talking about product led sales, and bring people who are eager to learn, communicate, and debate. And then the community organically grew to now close to 1300 folks, who are all talking about product led sales. The conversations within the community are what then drove our content. Our content is what drove the category creation.

In this process, we've spent very, very little money on our community. It's really organic, all about leveraging and tapping community members to host an AMA, to facilitate a workshop, to make introductions when you know it will be a valuable relationship for both people’s companies. And then they start talking about product-led sales and how Pocus has helped them do it.

Actually, I think the first real dollar we're spending towards our community is in a couple weeks, when we're having our first in-person meet-up. If you want to build a category, ask yourself, how do I take this group of evangelists and help them get what's sitting in their brain on paper, facilitate the debate and the communication, and then continue to take that and run with it? Whether it's in meetups, whether it's in content — keep going from there. Rather than thinking, how can I take my budget and throw it all into community.

Allison: One of the questions that I'm getting from founders that I work with is how to preserve cash runway. In particular, I've had some founders who are very experienced, have amazing networks, and therefore have been able to build out pretty senior teams on the go to market side earlier in their company than probably most founders would. That's amazing in a lot of ways, but unfortunately, it means that their cost structure is higher maybe than is desirable. So if I'm a founder, thinking about where to keep senior leadership in a product-led sales company, where do you think those dollars are best applied?

Alexa: It's an interesting question, and I think it depends on the stage of the company. If I had, for example, an early founding team of go to market professionals that I thought were stellar, and I wanted to build and grow with them, but I knew that we didn't have the burn, then honestly I would have the conversation around changing their equity and cash comp split. You can talk about your cash balance and runway, and say that if you want to be on the team, this is the equity-cash split that makes sense now. And we can re-evaluate in a couple of months.

When you're at the seed A/B stage, those early leaders also have to be executors. They need to be willing to get in the weeds, try things, and do the job as an IC, as well as a manager, with the long term vision that they're going to grow the team. With our founding team, we had the conversation around, yes, you could be a manager and a leader and scale out this team, but for the first couple years, you're going to be an IC.

Allison: So you're thinking that actually people should perhaps be open to taking pay cuts in exchange for maybe greater equity?

Alexa: It depends. I'm thinking more of who you're going to hire. There are some hungry people that say, "Look, I believe in your company so, so, so much that I'm willing to do anything for it. And if I need to take a pay cut for the first year because of the conditions we're in and have it in exchange for equity that may be more in the long run, I'm willing to do it." Obviously, that's not everyone's situation, but I think that is often a really good indicator of someone who genuinely believes that this is going to be something huge in the future. I would hold onto them.

In terms of your existing employees, I think it depends. I think pay cuts would be tough. I think that there's a lot of different things that I would do. I would maybe have that conversation around the equity comp split. I would think about some folks who, if you say they're a great leader, but we might not need them for the next two years because we need someone more junior, maybe bring them on as an advisor and switch it to more equity than cash comp. There's probably a lot of creative things you can do.

I'll say if I find someone that is special and incredible, and I know they're going to be part of the Pocus journey forever, I will hold onto them regardless of what it takes and make both work. I don't believe in having to say “either, or.” I think of, “make the ‘and’ work.” So make us be able to have the runway and keep them around in some form.

Allison: I've heard that the cost of advertising may go up in the future. I don't know a ton about the subject, but given, for example, increasing privacy requirements, it might just be more difficult and more costly to reach your audience. And I'm wondering what that means for product led sales companies. I know you said earlier that, particularly entering a recession but also in general, it's good to have more of your leads coming from organic sources, less from paid ads. But I am curious, if I'm the kind of company that has a meaningful amount of my pipeline coming from paid ads, how should I think about what might be the future of the cost of advertising and how to allocate my spend?

Alexa: I would be interested to actually dive into the numbers here, but I'll tell you anecdotally what I observe. I think really good product led growth companies have a strong self-serve flywheel. In the early days, the leads may have come from paid advertising, but now it’s more about the virality and community effect that drives it. You need to start that flywheel so that the cost of acquiring every new customer goes way down.

I'm thinking of Notion, for example. It took them a couple years to get up and running, but then they started to recognize that there were a bunch of folks that were using Notion and getting paid to actually build Notion templates. And then they were actually ambassadors of Notion informally. So what did Notion do? They hired these ambassadors and said, keep spreading the word. Find new areas. Start a community in this region and this industry around how they can use Notion.

For good product led growth companies, they tap into product hacks and growth hacks in community more than just paid marketing. That's also how we run Pocus. It's all around community and content versus paid advertising.

Allison: That's really smart. One of the other concerns that I've heard circulated a lot in our industry is about tech companies that sell to other tech companies. In a way, this influx of capital over the past year has been self-referentially fueling tech companies' growth. You put more money to a tech company, then they sell to all your other portfolio companies, and then they're able to raise more money and sell to the other portfolio companies. It's a flywheel from there, which you could imagine crashing down when capital becomes more scarce. In particular, the tech industry has been affected more than other industries by the recent downturn, since when interest rates go up, it discounts future cash flows, which is really what the valuations of tech companies are largely based on, it's growth that's coming in the future.

Alexa: Totally.

Allison: So if I'm a tech company selling into other tech companies primarily, I might be a little concerned and eager to diversify. I'm wondering, especially how does this potential trend affect product led growth companies? I would think that tech people would be more likely to sign up for self-serve products than non-tech people. Although I don't know if that's the case, but I am curious just to know your perspective on, if I'm a PLG company, how should I think about this vertical segmentation of my customer base and how to evolve it over time?

Alexa: I'll answer the question first from the perspective of any tech company, and then I can narrow into product-led companies. For any software company — and I was just talking about this with my team — now is the time to not be a nice-to-have product. You must be a need-to-have product if you're going to sell into other B2B software companies. And so what I mean by that is there has to be such clear ROI on revenue generation or time saved.

That’s what we've been narrowing in on at Pocus. We are a revenue generating product for other companies, and we can save them time. So how can we show our customers that we are saving them 10 engineering heads for a big fraction of that cost?

For product led companies, I think that absolutely still applies. If you can play the long game of product led growth, and you have the capital, it's great to be able to take the time to build those self-serve fly wheels and become really embedded in organizations with that viral growth. A lot of the best PLG companies did this: they weren't charging a ton in the early days, because their goal was more around activation and adoption than revenue. I can think of a lot of our customers right now that are doing that. Then once the market is in better conditions, you can go in and have a really good story of, “We're now in every single one of your organization’s departments. We can roll this up into an enterprise license. And once we go from free to paid, you're going to be saving millions of dollars.”

I know that not everyone has that opportunity, but I do think a lot of well-funded PLG companies right now — which feels like a lot of companies — can play that game.

Allison: It seems like in general, a lot of companies are trying to move up market into enterprise in this moment. What are you noticing with the companies that you work with?

Alexa: I'm going to have a hot take. I think that's something that investors like to say. That's what we've seen in the past worked. What I think is, get creative with your go to market and do what works.

I was doing a lot of thinking about past recessions and where have people either shifted their product or their go to market motion, and there's proof that recessions and down markets can lead to breakthrough companies. You think of Airbnb and COVID, where everyone thought Airbnb was dead. I remember saying I'd never book an Airbnb again, but they just took all of their resources, and people allocated it towards long-term stay. And so what I mean is they got creative, they fixed it. They said, okay, we're going to have a different go to market and strategy. We're not going to do the one week Airbnbs. We're going to do the three month Airbnb.

And that's the same for every company. Maybe your strategy is, I don't want to be SMB self serve right now because I don't have the capital to play the long game of PLG and I want to go up market. Great, experiment with that. I would say be data driven, be personalized, make sure that you're constantly checking that that is working and that you're pulling revenue forward at a very faster rate than what you were doing before.

It depends for every company. I would just say, be very creative, diligent, and agile through the process.

Allison: All right, Alexa, this has been an awesome conversation. Any last tips for folks who are trying to manage their go to market through a potential downturn?

Alexa: It's a good question. I would say, just to repeat what I've said before, if you're product led, I would double down. If you're sale led, I would start thinking like a product led company, find ways to reduce friction, find ways to add value through automation versus humans, and just get creative. Instead of trying to throw a lot of heads at a problem, think through how you can optimize growth, activation, and onboarding with the fewest amount of resources.

Allison: Alexa, thank you so much for joining us today. This was great.

Alexa: Thank you for having me.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

One of my favorite topics is the future of operations, because it's on the rise, as a function and a concept. Founders are obsessed with scale, and the company-wide platform and glue that comes from a strong operations effort is pivotal to that scale. As a result, my hunch is that operations -- both in terms of roles with that title, as well as people more broadly who identify as systems thinkers -- is growing as a percentage of headcount. And that means that there are abundant career opportunities in this area.

One of those career opportunities is to develop a no-code skill set. Phil Lakin has built a vibrant community of no-code builders and more recently started a company called Switchboard that seeks to provide infrastructure for that community. In this conversation, Phil shares thought-provoking ideas about:

* Given the maturation of the no-code space beyond a community of mere "tinkerers", what career paths now exist?

* What are the best-of-breed products in the no-code stack?

* What does the no-code space look like 5 years from now?

I hope you enjoy this conversation as much as I did, and feel free to reach out with any ideas or feedback for either Phil or me. Let's dive in!

If you’d like to hear more about scaling companies via operations, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about:

* Switchboard (Phil’s company!): Product Manager

* LaunchNotes: Director of Engineering

* Kingdom Supercultures: Head of People

* Guide: Head of Marketing

Transcript

Allison: Phil, I'm so excited to have you on the podcast today. You are definitely an intellectual thinker when it comes to the no-code world. I think you have interesting theses about the direction of that community, and I'm excited to dive into them with you today.

Phil: I am super jazzed to be here. Pumped.

A: To start off, tell me what are the two or three biggest trends you are observing in the no-code community right now?

P: No-code is definitely a term that has grown in size and scope. It's been around for a long time in one form or another. Everywhere from Excel, to WYSIWYG, to building with Squarespace and Weebly and Wix. And now all the way to applications and workflows and dashboards.

The big trends that I'm seeing right now are: One, folks are moving away from using one platform across an entire company. They're using multiple platforms — best-of-breeds working together. Just like developers, they’re using multiple tools to accomplish a big goal.

Also, no-coders are getting comfortable with using multiple tools to accomplish a goal across different departments. Tools are starting with teams and then making their way across companies. I often see that one team at a company — say the marketing ops person on the marketing team — will start using a tool. And then someone in sales will go, "Whoa, how did you guys accomplish that?" And then they'll want to start using the tool. I definitely see a lot of product-led growth, with tools landing and expanding within this space.

I'm also seeing more folks thinking about how much farther the envelope can be pushed with no-code. There's a lot of talk about building your first product with no-code, or building your MVP. But I'm seeing more folks think about, "How do we make long-term investments in no-code? How do we make no-code go beyond just prototyping? How do we make it the thing that we rely on that can move the speed of business and actually stay there for operators and not ever get moved to code?"

A: You mentioned in particular that you're often seeing no-code solutions spread across companies from function to function. Where did you notice no-code skills being concentrated within most companies? Are there particular functions where you're seeing those skills the most?

P: We see a lot of operations roles: sales operations, marketing operations, people operations. My wife works in people operations at a company called Guru, and every now and then over dinner, we're talking about Zapier.

Typically, it's the operations function within these non-technical departments. But if the team is really small, sometimes we'll see an IC or a manager of those departments come in and fix something with no-code.

A lot of folks in these roles are already no-coders at heart, but they don't even know there's a community, or a term, or a set of tools beyond the one or two tools they used to just fix the initial problem they needed to fix, without little developer support.

A: Do you think that these Ops functions where no-code expertise is concentrated will continue to report into these individual business functions like Marketing and Sales and even People? Or do you think Ops functions will congregate over time into a separate, independent Ops function that then serves the functions?

P: Oh, I've got some hot takes on this one.

A: Love it. Tell me your take.

P: There's a push and pull. On one side, it is good that the functions get to do this type of work themselves, because the whole reason that these marketing ops roles and sales ops roles got verticalized into these different areas is because these functions were tired of waiting on a centralized function that was prioritizing against everybody else's needs, whether that was development time, BI time, data time. They just wanted to have their own person, their own MacGyver to figure out how to do something. They wanted someone to figure out how to get data from a web form into the Airtable and maintain it. So I don’t generally see there being just a no-code operations team at a company who is just doing all the work for every single department.

There's another term called “citizen development.” There are essentially four roles in the no-coder world. There's the end user, the contributor, the builder, the enabler. What I would like to see in the future is that, if there's anything central, it’s the enabler — the person that's helping choose the right tools, helping set up the guardrails, and clearing the path for people to be as flexible with those tools as possible. So ideally there are one or two folks sitting in a centralized capacity who maybe will report up to IT or the devs, where their job is to translate and make sure that the policies are met and everything's in place. That we're not duplicating work across different departments. That all the tools are security compliant.

But at the end of the day, they are not the ones building things, because you always want to keep the builders closest to the problem. That's the promise of no-code. And you just don't want to lose that instinctuality.

A: Super interesting. Can you describe the other roles within No-Code that you mentioned and define them in a little bit more detail?

P: You have the end users. Often they are your internal users, other employees at your company. You have to treat them like that when you're building no-code. A lot of times people just want to throw things together and build them super fast for folks internally and not treat them like users. But you should do user research and usability testing. That’s really, really important for internal people, if this is going to be a large part of their day to day job.

The second role, the contributor, is once step above that. You open up some permissions to someone to customize their own settings or workflows within a very guardrailed environment. At Compass, when we had a no-code system called Enboarder running our onboarding for our real estate agents across the U.S., we would give managers in certain locales the ability to change some of the things in their region that went out to their agents. So they would have the ability to do that without needing to involve us.

The third role is builder — the architect. They're identifying problems and architecting the solution. They're working cross-functionally to build it, deploy it, manage it, maintain it. So they're part product manager, part developer.

Down the road, I think we’ll see more and more of that fourth role — the enabler function, that head of citizen development, or that no-code program manager — whose sole job is to remove obstacles from both sides of no-code, because sometimes no-code moves too fast, to its own detriment. So, slow it down a bit. This enabler role keeps it on the rails, sets up the right environment, and interfaces with IT, security, and devs.

A: I'd love to double down on the tangent that you opened up about the challenges that no-code folks often face within their companies. You mentioned this enabler role that allows no-code experts to flourish and be more productive. What are the other primary challenges that no-code folks are encountering within their organizations?

P: We’re directly thinking about these at Switchboard. In particular, this mindset of, "Let's use multiple tools to solve a problem, use best-of-breeds, use some kind of database, some kind of integrator, some kind of vertical SaaS and mix it all together and produce a very complex and robust solution."

But just because it's no-code and was easier or faster to set up, that doesn’t mean it doesn't bring some of the same challenges that code does. It needs documentation and maintenance. It needs some of these things that the world of dev ops had for years and years and years. That's because no-code has started to go through this maturity phase, where it's moving from tinkering and experimenting into, "No, this is core infrastructure."

I see big tool sprawl. Everyone's using a lot of different tools. We need governance, permissioning, documentation.

We started at Switchboard with monitoring, because we saw that you can't rely on things that you can't monitor super well. And so we wanted to build monitoring as a starting place, but we think that the world of no-code has to mature to the point where there could be a level of infrastructure over all of this stuff.

I think security is important. Making sure that the right data's going in the right pipes, that compliant data is not going into places it shouldn't be.

I also think another critical issue outside of the tooling and the infrastructure is education. Oftentimes a company will actually have a lot of tools they need to solve a problem and not even know it. But people want to go out and find a new and shiny thing. It's unbelievable what you can solve with current resources, if you just do a little bit more digging.

So if I were to sum up all these challenges, I’d say that the speed, agility, and flexibility of no-code is a double-edged sword. The goal over time is that market matures to dull just one of those edges of the sword, so that it can move really fast, but it doesn't come back and get you on the other end.

A: Thinking about the maturation of no-code. Usually in industries like this, you start to see real career paths developed for people. It's no longer, as you said, just the sort of tinkerers or early visionaries that are using it. There's people who are shaping their professions based on their skill set in this area. So I'm curious to know nowadays, who are the people that are going into no-code? What backgrounds are they coming from? For example, if I'm a founder looking to recruit a no-code expert, where would I look? And how are you seeing their career paths evolve over time?

P: Some folks start to found company with no-code. But the biggest entrance I see into the no-code operations world is typically someone who worked in CX, sales, or marketing. Or people who started leaning a little bit into systems, learned that they could do way more than they thought was possible with the right tool set, started doing that, then started getting relied on to do that, they got promoted because they did that, and now they want to learn even more.

Take me, for example. When I started in tech, I didn't even know the calendar invite. But all of a sudden I have responsibility for a major onboarding program that onboarded over 25,000 drivers compliantly through a frontend and backend application. That was all because I started tinkering with no-code, then started pushing and pushing and pushing and pushing.

That's the main career path that I see: you’re working at a company that has these types of needs in some type of non-technical role. If the company's growing, they're going to need someone specialized in the systems that you've now built and have become critical. And then you'll probably work across multiple business units to do that.

If you want to hire these types of folks: First, we have a job board. The community that we run, No-Code Ops, literally has a job board, nocodeops.com, where we post roles like this and we share them through the newsletter.

On Deck also has a great program for no-code operations, and no-code founders. I was the first cohort of them.

There's also a career path for people that want to work as a consultant or at an agency. Go to Zapier's expert page and see how many people built their entire careers, making hundreds of thousands of dollars a year, building automations and maintaining them for companies.

A: That's really inspirational. One of the questions I get a lot from operations folks is, there are so many products out there that I could be learning right now. How do I choose which ones to work with? And I think I would add to that, how do I choose between no-code versus learning other SaaS applications? Or is that a choice? How should I think about, am I a no-code person? Am I not a no-code person? And generally what I should be learning right now?

P: I see no-code as a spectrum. There's hardcore vertical SaaS — your CRMs, your help desks, and other SaaS built for a specific purpose. The less specific and the more custom it gets, the more it’s no-code. There are parts of those SaaS platforms that are no-code; for example, HubSpot has its own automation platform that is no-code.

It doesn't matter what tool you start learning. Our job as no-code operations professionals is to find the best tool for the job. Sometimes the only way to do that is to go in and mess it up offline a few times. How far can I get with this? How much of the solution can I do here? It's a lot of experimentation.

I built that onboarding application in six, seven different iterations of different sets of tools before it finally arrived at the point where we could onboard a driver offline in 20 minutes, sync the iPad later, and the next day they'd be driving for us, compliantly. That took six months of experimentation to get to.

There are a lot of Venn diagrams: "This tool does this really well, and this not so well, and this pretty good." You make those decisions over time, but it's a lot of experimentation.

I’ll add that a lot of us no-coders are on Twitter. You can ask, "Hey, if I were to want to build something like this, how would I build it?" The community's super supportive in that way.

A: What are the most popular products in the no-code stack? Maybe a slightly related question would be, if I want to develop a best-in-class stack with all the best-of-breed solutions for different pain points, what comprises that stack?

P: I think of no-code in a few different buckets when it comes to internal operations. You have your vertical SaaS, your data, your automations and workflows, and your frontend-ish applications. For the data side, Airtable is of course best of breed. It's a spreadsheet meets database. So you can really learn database structure through it. It's pretty phenomenal. You can rely in it up to a certain extent as a database. So you can access it from different places. It has the interface of a spreadsheet. So people can get super hands on with it.

From an automations and workflow perspective, for if-then statements, Zapier is number one on that front, in terms of ease of use and how many applications it supports for different vertical use cases. And for enterprise use cases, you're looking at tools like Make, Tray, Workato on that front.

And then, if you're also thinking about syncing data between tools, that’s Polytomic, Syncari, and Whalesync. They're all thinking about, how do you keep data in sync between different places, especially in a decentralized org.

Then there’s the category of building applications from no-code — front end, backend, everything. Bubble is for external — building for customers. I love tools like DronaHQ, Betty Blocks, Kissflow. Then there's one on the orchestration front that I think is really powerful, which is moving data between places, but with a lot more human to loop syncing, which is Tonkean.

A: I think a lot of folks who are looking to get into the space as experts will find that list very helpful. Switching gears a bit. What inspired you to build Switchboard? And can you tell the audience a little bit about what it is and what you're focused on?

P: Our core thesis is that infrastructure is the big missing piece for these no-code tools to really enable business users to solve these problems at scale internally. And so, what we started to build was the first product of monitoring. We wanted to make sure that if you're relying on tools like Integromat and Zapier for business critical processes, you never miss an error — that the error finds its way to the right person in the right place, in the right channel at the right time, and if they don't respond, we escalate it. So we essentially built PagerDuty for no-code integration tools. There will be more tools that we're going to be integrating with.

The next step of Switchboard is building out some other features of the dev ops suite into infrastructure that sits on top of all these no-code tools as well — not only the integrators, but also places where data is living. If we do that well, then no-code operations can become multiple people's responsibility. When it's just one developer versus 10, when only one person's being relied on for no-code, it can only go so far, but if people can truly collaborate and make it a multiplayer experience that is safe and reliable, then the sky's the limit. We want to enable that, and we want to enable people to use the tools that are already using. The future we don't want to see is everyone being forced onto one platform, like an all-in-one. Or everything has to be handed off to devs at a certain point. That's what we're building at Switchboard.

A: Love it. No shortage of challenges and opportunities ahead. When you think about the no-code space five years from now, what looks different versus today?

P: I had a really good conversation with Wade, the CEO of Zapier, about this, when I was in Austin. He said something along the lines of, "I hope in the future, this thing is just called work, it's not called no-code." I was like, "Yes!" The idea that it doesn’t feel hyper specialized, because if you have a problem at your job that's solvable from a local level, but it could be impactful on a global level for your company, you should have the ability to build it, share it, and use it as long as you’re within certain guardrails. Think of how many folks out there know exactly what their company needs to do differently but aren’t inspired or enabled to do it. I think in five years, this stuff will be a lot less scary to people.

Does it replace devs? I clearly think the answer is no. But I think the answer to that will be way more obvious in five years than it is right now.

A: That's a very inspiring vision. And I'd love to end on another inspirational note, which is, if you had to offer one tip to people who were looking to build their careers in the No-Code space, what would it be?

P: I'll take that from two different angles: Let's say one, you're already working somewhere; and two, you're looking for your next thing. So if you're already working with data in some capacity, but you're not directly responsible for the technical side of the business, I would recommend finding a current problem that your team faces that you’re genuinely curious about and solving it. Get approval from your manager to spend 10-15% of your time doing it. Then take dummy data, so don’t connect it to your live company stuff. Explore different freemium options to be able to solve that challenge, then show it back to your manager. Their jaw will be on the floor.

If you want to dabble in this space and explore what it is to be consultant or get hired full time as no-code operator somewhere, I would start looking at some of those tools that I listed earlier. Start building something. Ask friends at small businesses, "Hey, if you could have something that does a thing that would be impactful for your business, what would that be?" And just build it, see how far you can go.

No-coders are just like coders in that they learn as they build and have new challenges. You'll be shocked how fast you can get up to speed to the point where you're valuable as a consultant.

A: This was a really empowering message to folks. Thank you for offering your wisdom to a lot of people who I think will go and try to seize this opportunity. And looking forward to continuing the conversation.

P: Same here. Always good talking.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

Not everyone is a late-stage, overvalued company laying people off right now. There are many founders out there who are gearing up to announce their company — and they want to make a splash, hire people, and bring in customers!

Ryan Narod is an expert on strategizing for your announcement. He leads marketing at Mutiny, which recently announced their Series B from Tiger and Insight (and me!). We discussed topics such as:

* What are the components of a top-notch announcement plan?

* How do you work effectively with the tech press?

* How should you prepare for the aftermath of the announcement?

I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about:

* LaunchNotes: Director of Engineering

* Kingdom Supercultures: Head of People

* Guide: Head of Marketing

Transcript

Allison: Ryan, thank you so much for joining us today.

Ryan: Glad to be here.

A: You have done really incredible things for marketing at Mutiny, which is itself in the marketing space. So I think folks who are listening are going to learn a lot from you about how to prepare for their launches. I'm excited to pick your brain. Do you mind sharing just a little bit about your background and a bit about what Mutiny does?

R: Sure. I lead marketing at Mutiny. We help marketers increase conversion rates on their website. If you think about the market downturn that we may be entering when the era of growth is fundamentally coming to an end, the idea of you needing to get more out of your existing channels and spend is actually more important now than ever before. We help marketers personalize their website, show relevant content to folks that are coming to your site, so that they convert at higher rates.

I've been here for about a year, prior to that have been a Mutiny customer, one of Mutiny's earliest customers at a company called Radar where I led marketing. Before that, when I was at Google, I actually built a product internal to Google that was similar to the problem that Mutiny solves, so I've been in and out of this space for a while.

A: You've been knee deep in marketing in one way or another, whether you're leading the function, or building products for it, I'm sure you're drinking the champagne as you go.

To start, I'd love to talk about timing. So what factors do you think should impact the timing of a launch?

R: It depends what kind of launch you're doing, whether it's a funding announcement or a product launch. I'll assume you're talking about a funding announcement because that's what most of the launches are geared around. The thing that influences when you want to launch is not when you get the funding, it's what do you want people to think about your launch? When do you have something interesting enough to say that essentially the main takeaway of your message will be, this company raised money, but they've also launched a solution to this really interesting problem. I always try to bundle funding announcements with some sort of product innovation that connects to the category that you're trying to create or disrupt.

The second thing is market conditions. You want to be sensitive to the times that we're in. You can never predict the market conditions, but you want to be flexible. And so if tragedy occurs in the world, you need to be respectful of that. I'm sure there were companies that were planning a launch around March of 2020. It was important to be able to take a step back, reassess, and think about, is the problem you're solving appropriate for the times that we're in?

A: Those are really interesting factors to consider. Notably, you didn’t mention when your competitors are launching. Should you try to rush to be first to market? How should the competition influence your decision?

R: It's hard to know when your competitors are launching. You should in general have an eye towards the future, and competitors tend to be in the rear view mirror, or at least it's helpful to think about it that way. Yes, you should be first to market, but you can never know when a competitor's planning something. And certainly that shouldn't be the guiding principle behind when and how you launch.

A: Let's say I'm creating the launch plan. What are the components of a great plan?

R: It starts with clear goals. Those are numeric goals, but also the non metric based goals. What do you want people to think and feel when they see your message? What problem are you solving? What category you are creating or disrupting? I always start there and fill in the sentence: “When people see this news, they will say X, Y, Z.” If you're able to articulate that, I think it guides the type of launch that you have.

The second thing is, don't lose sight of the news. Like, what are you actually launching? I think this is where folks get really, really tripped up. They try to bundle the products with the category, but what is the news? What feature did you launch that people are now needing to pay attention to? And with that, what are the key points you want to get across?

The third component is the CTA [call to action]: what do you want people to do? This is where I've seen companies have way too many CTAs: we're hiring, contact sales, play with our demo. An example of something we did was, we created a low-friction way for you to interact with Mutiny and try the product without requesting a demo, without contacting sales. You can go out our website, you can punch in your website domain, play around with the product, and see what personalization can do. We built that purely because we knew a lot of folks would hit our site, not all of them would be ready to talk to sales, and we would've given them one really unified CTA to try our product and experience the magic.

Think about what channels you want to activate. PR is typically one that folks prioritize, but also social. Do you want people talking about the product in Slack communities? Figure out all the channels where you want to launch.

Another one is your advocates. You're not going to do this alone. You have customers who are your advocates, your investors, your employees. I think this is something a lot of people who are doing launches tend to forget, but you have to think about each of these audiences and preparing a plan for getting each of these audiences to amplify your message.

I use the word plan because I think a plan is what pulls all of this together. It's a lot of work to pull off a complex launch. It takes many months, it has a ton of dependencies, and it's really an all team effort. You need to be a good project manager to facilitate all of these pieces coming together at exactly the right time, like clockwork.

A: That's very comprehensive. Are there certain milestones that you think folks should keep in mind in terms of the timeline? For example, I've noticed some companies being really thoughtful about first, the TechCrunch article comes out, and then we've got another blog post that's teed up. How should I think about the timeline?

R: Well, when you are trying to get press, you typically want to do an exclusive, which means you give the reporter the first right to publish the story. Typically they don't want any news coming out before the story is public. You have to sequence everything based on that. You'll agree with the reporter on, here's the date when the news is able to go live — it's called the embargo date. After that, you think about all of your follow-on launch assets. Then your blog post can go live. Then all your customers can go crazy on social, then all your investors at that point.

A: You mentioned a little bit about this, but how do you tee up an article with the tech press? Do you have any tips on working with them?

R: The most important learning I've had is being intentional with the reporters that you're targeting. I've seen a lot of PR firms give pretty bad advice around, you need to build a list of 50 reporters, and then you need to either batch email them or email them one person per day, give them a 24-hour turnaround period to respond. The reality is most tech companies are not Tesla and you're not Elon Musk. So you need to give them enough time and be patient and intentional. What I like to do is pick three to four reporters that are the perfect fit for your company. These are the ones that you're willing to give an exclusive to, and you should be able to articulate why are they the right ones to cover your company and then find every single way to get in front of them. Don't just like cold-email them the same template, but write really bespoke intro blurbs, and try to get in front of them through intros from your network or from investors. Cold emails can work, I've seen companies get creative, use their own products to get in front of reporters. It’s okay to get creative, but it's not okay to get annoying. It's a delicate balance.

Some outlets are cut and dry. If you have a funding announcement over a certain amount that you raised with top tier investors, TechCrunch should usually cover it. They're pretty formulaic with how they approach funding announcements. They have a standard set of questions that they'll ask you. If you're trying to go for more mainstream media, you need to connect it to a broader trend.

For us, we found this perfect reporter at Forbes who cover CMOs. The angle that worked for us was that CMOs are putting their own money into this company, they're angel investing in Mutiny and this company is solving this problem that they'd been facing. There was a lot to that story that we were able to bring for the reporter. We were able to get the reporter access to interview top CMOs, who rarely give interviews. As a reporter who covers the CMO beat, we became an offer that he couldn't refuse.

A: That's a really interesting example. It sounds like in your case, the reporter was really familiar with the space that you were operating in. Do you ever find that some reporters are less familiar and in those situations, how do you educate them about what your product does? I'm thinking, especially for more technical products, this could at times be a challenge.

R: The first thing I would say is when a company is early stage, it may not be best to ship for the moon and try to go for The New York Times. There happens to be plenty of great reporters at outlets like TechCrunch, who do cover all kinds of niche, technical topics from cloud security to infrastructure and everything in between. Really try to find a reporter who covers your space. In the off-chance that there's no reporter in the world that has written about a company similar to yours, which I would find hard to believe, then I would ask, what is the closest similar industry and who is that reporter? I think it'd be interesting to them to draw parallels like, hey, you cover this space, we're kind of like that, but we're different in X, Y and Z ways, and connect what you're doing to a space that they're deeply familiar with and educate them that way.

A: You'd mentioned earlier, when we were talking about the components of a good launch plan, that you should include your customer advocates and your investors in this. Can we talk about the more detailed tactics for exactly how to do that?

R: The first thing I'll say is with advocates, be it customers, investors — they want to help. Investors always tell us that they feel underutilized. Most companies underutilize their networks. Customers want to feel that they are on the cutting edge in using your product and want to brag about that. We may be guilty of over leveraging our networks, but it's really baked into everything we do, it's baked into our goals. As an example, investor referrals are baked into our growth and demand gen targets. There’s someone on my team who owns that number.

The other existential thing to keep in mind is that in exchange for helping, investors and advocates want to feel like they're in the loop, that they're not just being used but that you are giving them the inside track, whether it's giving them that feedback loop, “thank you for the referral” or “your post really helped us in this way.” That's the way to think about the give and get there. For launches specifically, I would say, make their lives easy, be specific about what you want from them. If they have a podcast, maybe you want to join an episode. If they're active on Twitter, ask them to post on Twitter and make it easy for them. We write blurbs for every single person that we ask to post. We'll write a blurb and say, hey, feel free to put this in your own words, but we would love if you could hit on these key points for us.

For customers, we created images that they can post on social containing screenshots of the experiments that they ran and the leads that it drove. It really helped pave this unified message where, when we had our launch, everyone was saying, "we're seeing you all over Twitter, all over LinkedIn." We had really amazing control of the message through these assets that we created for folks. But it wasn't all coming from us, it was being shared with all of different networks of folks that we have access to.

A: Let's say you execute your launch plan. You're very successful. Now you've launched and you've started to receive a lot of inbound attention, whether it's from potential customers, potential hires, potential investors. How do you prepare for that potential onslaught?

R: Everything arrives at your website. Your website is your front door. So we created a checklist to think about what will leave our website most compelling and reduce friction. You mentioned hiring: every hiring manager should have their roles open. It's a simple thing. Messaging is a little bit more complicated, but you now have talking points that you used with the press, and you have what people are saying about you on social that you are orchestrated, so the last thing you want to do is have your website messaging not be aligned to that. Align your messaging with the campaign.

Next thing is case studies. Folks are going to come to your site because they think what you're doing is really cool. Well, they should see front and center how other customers just like them are leveraging your product and what kind of results they're seeing.

I mentioned the CTA. I highly recommend having a low-friction CTA for folks who aren't ready to book a meeting, but still want to see what your product is all about. If there is an opportunity to build a demo environment or somewhere where people could poke around with your product, without submitting a demo request, that's always a great way to deliver on the value and impress folks who are coming to your site after launch.

The last thing is, some people will want to meet with you because you solve a problem that they have. You want to make sure that they can book a meeting right away without having to fill out a form and wait days for you to process through hundreds of leads. Whether you’re using something like Calendly or Chili Piper, both are really great tools for making sure you’re giving your prospects the calendar availability that they could book in real time.

A: When do you think it's appropriate to get external help with your launch, whether it's from a PR firm, agency, a consultant?

R: I think there probably comes a point where that makes sense. I would say we recently announced our series B, and I still don't feel like we're at that point. We went down this path of exploring external help from agencies and PR contractors. They’d say, you want to get an article in Forbes, that's impossible. There is a lot of bad advice out there. It's really hard to select the right partners for something that's mission critical. This isn't that hard to do yourself, and a lot of the hard work is actually has a lot of internal dependencies. It's like digging up interesting data. It's really like deep message development. That's something that it's hard to outsource.

Outsource things that are easy to outsource, for which you don't have an in-house competency. We outsource the creation of graphics to a designer. There are certain aspects that don't have internal dependencies, and I recommend outsourcing those.

A: Let's say I'm a founder who has really deep technical expertise and experience, but marketing is not really my strong suit. Maybe I'm a late seed company, or I just raised my series A, and maybe I have a junior marketer on board. Do you think it's typical in situations like that for this founder to delegate to that junior marketer to run the launch plan, or is this something that the founders should take on themselves, or should they be hiring a more senior marketing leader?

R: It's a great question. I think there are a lot of great templates out there on how do you run a launch. Play Bigger has a good template and framework for how to create what they call a lightning-strike moment. The piece around project management, wrangling all the stakeholders, I think that can be delegated. This is something that the founder can delegate entirely, not be involved in so much in early stage. Much of the message development comes from the founders' own words, and I think the founder is going to need to be really highly involved, but I think some of the pieces around, let's go email all of our customers or let's go email all of our investors, I think the tactical pieces can be done by more of the junior person. But I highly recommend that the founder stay involved specifically at message development, figuring out the right reporters, strategically what are the goals. Ultimately the founder is the spokesperson for the company and so they can't just take the approach of, tell me where to show up and I'll be there.

A: What do you say are the most common mistakes that founders make when they're launching?

R: The one that I see most often is thinking that press it's going to be the silver bullet. When we got press, I'm pretty sure we drove more traffic to Forbes than it drove to us. My biggest advice there would be, use all the channels you can to get in front of your ICP. Ultimately the press becomes a super valuable proof point. A lot of founders get an article at TechCrunch and then sit back and expect that their inbox is going to be flooded. But TechCrunch probably puts out dozens of articles a day.

A: Really good advice. Any final tips for founders or marketers out there who are trying to gear up for launch?

R: My biggest learning here is just be really intentional. This is not a volume game of, go and email some half-baked message to hundreds of people, reporters, press, analysts. This is a game of intentionality, being intentional with your messaging, thoughtful about your CTAs, being thoughtful about what products you are bundling together with this launch and ultimately being thoughtful about who needs to hear about it. So it's less about doing a broad scale and more about homing in on who are the people that will care about this most, because once you nail a really good story, it's up to you to distribute that and get that in front of as many people as possible.

A: Ryan, this was an awesome conversation. I took away so many learnings. Thank you so much for spending time with us today.

R: Awesome. Thanks so much for having me.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

NFTs are known as a consumer trend. But with every new consumer need, there are businesses looking to offer a solution, and there are other businesses that want to help those businesses. Which means that there are now B2B companies enabling the NFT ecosystem.

I discussed this topic in my latest podcast episode, with Lisha Li, CEO at Rosebud AI. We covered:

* What opportunities has the NFT world opened up for B2B companies?

* How did Lisha pivot her Web2 company into a Web3 company?

* What does Rosebud’s Go-to-Market look like?

I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about:

* LaunchNotes: Director of Engineering

* Kingdom Supercultures: Head of People

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* Guide: Head of Marketing

Transcript

Allison: Lisha, thank you so much for joining us on the podcast today. I'm so excited to chat with you about what's going on in Web3 and the movement that you are part of and helping to champion.

Lisha: Thank you for having me. I'm excited to chat.

A: To start off, how did you start your company and why? And how did you get into Web3?

L: Web3 was definitely later in the journey. Our focus and my background is in machine learning and, in particular, deep learning. I was really passionate about the developments in synthetic media: generating visuals, videos and creating creator tools, to help people make visual assets.

In the beginning, we were launching a bunch of mobile apps and some of them went viral, because their focus was on making the interface stupidly easy for anybody to try to engage and start using these models. But what made us seriously consider a Web3 pivot was the fact that it became clear that there were some very serious, long-term application in the NFT space.

In particular, many gaming applications were developing gaming assets and minting them as NFTs — which can have a huge financial upside, but also are a way to support creative work. The same was true for fine artists and other people creating visual assets outside of gaming. I was super passionate about that use case. It became clear to me that if I wanted to focus on those types of users, then I should completely focus on creating NFTs and using our ML tools to focus on that use case.

A: Who are the customers that you're focusing on today, and what might they be, say, a year or two for now?

L: Right now we actually have much more of a B2B focus. Before, we were releasing consumer apps, and that was because consumers were the ones willing to try. I would call it prosumer. They were sometimes creating assets for smaller businesses, for their own TikTok channels. They were influencers as well. But yeah, primarily I would just say that's a consumer angle.

Now we partner or collaborate with other projects, whether they're launching these play-to-earn games or helping people launch NFT collections. An artist might want their mentors or their community to be able to co-create with them, but it's impossible for them to help a 10,000-person community create things in their style. But if we train a deep learning generative model — GANs, diffusion — on an artist's style of work or their portfolio, then we can actually facilitate that experience of interactive creation. Our value-add is to bring all of our learnings from creating consumer experiences to our work with these projects, to build interactive experiences for their NFT projects.

We raised a crypto strategic round recently, and our lead was Animoca Brands. So you can imagine they're involved or invested in a bunch of these gaming projects.

A: On that note, do you work with marketing agencies that might be supporting a celebrity client or someone else who wants an NFT that's in their image?

L: It's not something that we've started pursuing yet, because we had access to some artists directly. But with that said, I think it'll make sense as a go-to-market strategy because there are many NFT collections that are oriented around, "Okay, now people want to drop digital merchandise," and we can also help with that. Maybe not exactly marketing agencies, but maybe we’ll work with managers of talent, like creator talent, whoever is the solopreneur, that is looking to launch NFT drops.

A: For one of the gaming companies that might be working with you, what do you think defines success in their mind? If they're happy with their working relationship with you, what does that look like?

L: The thing we are both aligned on is, how do you drive more utility to the community? Back in 2021, NFTs were really hyped up. Anybody could do a 10K collection and probably sell out and make money. But I think those days are gone. You need to have a sustained reason for why the community is excited about not only NFT drops, but why are they playing the game or in the community. And so what would define success is the fact that we can allow the users, the mentors, the community, to participate in creation in some way. The metrics are, do people mint stuff? what is the actual revenue? and do people trade on it? The goal is to have metrics for sustained value and engagement.

A: Are these gaming companies trying to build internally initially when you go talk to them, or do they have some kind of alternative?

L: They don't have anything that's interactive. They're obviously very successful already doing drops, getting corporate partnerships, and creating these gaming experiences. But if they wanted to have a huge number of variations and unique variations, that's something we can help with, and we work with creative teams on that.

Also, it's just not currently possible for them to take any user input to customize it without working with us. To your point about what's a success metric, we're hoping to prove that this user input is valuable for community engagement.

A: So it sounds like you're opening up new opportunities that these companies previously didn't have. You're truly creating a new market. What do you think that market looks like five years from now?

L: In the short term, we want to see if co-creation can help make IP and proliferate these gaming worlds, and if community input can help with corporate merchandising.

I think what's really missing, especially in VR, is that the content creators are still limited to people who are extremely technical. What's really different in these Web3 projects is that you do have a lot of participants in the community who are consumers, but hopefully you can elevate them, at least a subset of them, to creators as well. I would say the analogy is very similar to how TikTok made it easy to make videos. It created a new class of creators, because it was stupidly simple to create a video, and so people who had things to say could now be a creator themselves.

A: With this movement do you anticipate there will be many more B2B companies operating in the NFT space, and if so, what do you think are the categories of B2B companies?

L: B2B is hard in the space, but also it's what people want to bet on first. Because if you believe that the ecosystem will grow, then it might be easier. So I've seen some API plays here, or Carta for Web3, where they help with token launches.

What we're doing belongs in a broader category, of how do you make NFT collections? Because I see the need not just coming from the visual part. In fact, the visual part I would say is very small. What we're latching onto is community engagement — that's what drives value.

If you're working with brands that want to do drops, then it's all about, how do you onboard people who aren't natively in Web3, and what value is it to them?

In general, I'm seeing a lot more tooling than there are applications.

A: Is there a certain Web2 company that you would consider yourself to be an analog for? Or if not, is there a Web2 company that you aspire to be like in some way?

L: Probably not as an analog, because the business model that enabled us to focus on these type of creators, whether it's in the gaming sector or fine art or creators, is just not possible in Web2. Also, the gaming industry has been notoriously difficult to sell into, and focusing on fine artists was not a venture model in Web2.

That said, there are definitely a bunch of companies that are working in the creator economy who inspired me in terms of how they built product and their business model. The first thing that came to mind when I was trying to think about the right go-to-market was Canva. I really like Canva because they had the strategy to templatize so many different types of use cases. It’s about making things really easy and accessible and then allowing people to achieve professional-ish looking results.

A totally different company in that category is GIPHY. I found it delightful to learn how they figured out the way to extract value. The real estate of where they showed GIPHY was getting so much attention, and therefore when they did deals with platforms like Facebook or Twitter, that's how they got paid, in views. And they also in some ways have made it really easy to create content.

A: Switching gears, I'd love to talk in more depth about your product itself. Can you describe, at the next level of detail, what exactly does your product do? What are the key features? How did you build it? What's your tech stack?

L: There's a lot of different models we use. At a high level, we are aiming to make it really simple to generate assets. It's easy in terms of a really accessible interface, such as somebody using text to describe it. It's like, "I want to create somebody with pink hair who is a fairy punk." It's whatever collection they want to make. There's some really great methods that have emerged out of deep learning, CLIP guided diffusion is one of them. That basically allows you to match natural language to other generative models that you were able to train. Diffusion was mentioned, also your good old GANs and basically a bunch of models where you can train it on a particular domain and then be able to reproduce very accurate samples from that domain, whether it's faces, landscapes, abstract concepts.

So that's 2D, but of course a lot of these things actually work also for 3D asset generation. You can imagine chaining a pipeline to create objects in 3D as well and populating an immersive environment.

Text is not the only interface that makes things super intuitive. Maybe we could enable some type of visual search, where you first have some random samples, and then you can look at their neighboring images. For example, I can make this person change hair, or age, or otherwise change dimensions that a user would be interested in controlling.

We want to give people control of creating something that's amazing and professional but with very little skill on their own. How do you give them the power to write text or choose visually what they want, all with a minimum number of steps, but still give them the feeling that they've contributed to the curation of something very unique?

A: This is mind-blowingly futuristic. It's so fascinating. Moving on to your go-to-market, can you talk about how do you price? Is this a subscription service? Are you taking a share of the royalties? How does it work?

L: This is one of the things that I loved about moving into Web3, because everyone kind of understands that people make money if we get a cut of the transactions. And so, yes, the royalties — the cut of the initial sales. There's some standards around how these projects are priced and the cuts that are shared. For instance, if you are a marketplace, you might take 5-15% of the cut, and that's depending on the value of the collectors that you can onboard.

For us, we're doing a lot of custom work for how the smart contracts will behave: There could be different tiers of NFTs that are associated with different privileges or properties, they may want a more custom minting experience, etc. So we'll probably take a much bigger cut, anywhere from 15 to almost 50%, depending on how much custom work. And then on top of that, we’re doing the actual ML work and creating the assets, so that's why the range varies so much. But that's not standard in the industry, though it’s something everyone understands. You're taking cut of initial sales and then also a cut of the creator royalties in the secondaries.

A: What does sales involve at your company? Do you have a sales team or aspire to hire one?

L: Probably eventually, but right now we’re still doing founder-driven sales. I think it's because the market itself is very nascent. I definitely have people on my team that do it with me right now, and that's because they're very close to the product or the content creation. They really understand, along with me, the vulnerabilities of certain things. Some things might look really hard but actually are really easy for us to do, whereas some things might seem to be really easy, but it's not something that we should actually be focusing any of our energies on. And so that's why I think we don't have a sales team right now, because none of those scripts have been really finalized yet.

A: That makes sense. Are there certain customer-facing roles that you expect to hire for in the future?

L: Definitely. We're in the process of onboarding a lot of community managers. In Web3, they will sit pretty close with product. They have to understand our offerings. They're actually also involved in the sales side of things, because we're not just creating NFTs ourselves, we're helping people and projects make NFTs. The more involved we are with these projects in terms of helping them mint and create that experience, the more marketing we do for them. So that's all customer-facing. And on top of that, we're merging our communities together so the customer is both the projects that we work with and their community of users, and our community that we've kind of already exposed some of these tools to.

A: Would you consider the community team to be the same as a developer relations team or are there some meaningful differences?

L: I think there will be meaningful differences, because our users are not developers necessarily. Most of them, especially if we're launching a collection with another project, will not be technical at all. They're co-creating and minting those NFTs.

A: What roles do you think will ultimately exist on your leadership team?

L: There are the obvious ones for tech leads. There will be an important role for a designer, because they would help on the interface of the apps but also come from an art direction background for these NFT projects. They might have some background in creating the art direction for games and also maybe visual movie products as well. This exec level role would be probably very unnecessary in most Web2 companies, but for us I think it will be pretty core.

A: Final question for you. What advice would you have for Web2 people that are looking to get into Web3 in their careers?

L: In my case I can speak most forcefully to the ML side, which was what really drove us to make the product. So the Web3 pivot just made a lot more sense from a business model point of view. And so if there's a company where you absolutely believe in the product, then I would say go for it.

Obviously there are a lot of scams. I'm sure your audience is very savvy, so that's not something that they're in danger of. But yeah, it is kind of easy to kind of start dipping your toes and just participating and seeing how they can get involved.

There are a lot of developer needs as well. You can definitely formally participate in projects without having to get a full time job and just test out if it's something that you like.

A: Lisha, this has been an awesome conversation. Thank you so much for helping me and others learn about the Web3 world, how B2B Web2 might be relevant and in what ways it's not, in what ways SaaS work experience doesn't translate exactly. But it sounds like there are a lot of parallels, and I'm excited to watch you continue to grow your company.

L: Thank you so much for having me. I'm sure I have a lot to learn from you on the SaaS side and how that translates. Because it's solving similar problems — a lot of those learnings probably carry over.

A: Sounds great.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

Product releases can be painful for many reasons. Employees may not be fully aware of what’s included in the release. Customers may have been waiting with bated breath for a feature that may or may not become available. Moreover, the product release cadence may not align with your sales cadence (e.g. quarterly targets) or your customer cadence (e.g. monthly check-in’s), which means it’s another rhythm that customer-facing team members need to think about.

In this podcast episode, I dove deep into the challenges of product releases with Jake Brereton, Founder & COO at LaunchNotes, which just announced its Series A from Insight (and me!). We discussed:

* How can you make sure that both your employees and customers are well informed about the product release?

* What are the biggest mistakes that teams make when releasing a new feature?

* What does a best-in-class release process look like?

I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about:

* LaunchNotes (the company that Jake cofounded!): Director of Engineering

* Workstream: Head of People

* Kingdom Supercultures: Head of People

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* Palette: Product Marketing / Head of marketing (US/Europe)

* Guide: Head of Marketing

Transcript

Allison: Jake, thank you so much for joining us on the podcast today. I'm very excited to have this conversation with you about how to communicate with respect to your product, which, for a lot of customer facing folks, whether you're in customer success, sales, or marketing, tends to be something that you care a lot about. Certainly customers care a lot about it. And product teams are trying to enable all of these groups to understand what's going on the product much more effectively. So I'm sure you have a big audience. And I'm excited to dive into the details.

Jake: Thanks so much, Allison. Yeah, it's a pleasure to be here. And congrats on the podcast. I appreciate the opportunity.

A: So to start out, I want to talk a little bit about your product, because I think it'll provide some context on the best practices that we talk about the rest of the conversation. Tell us about what inspired you to build LaunchNotes, which is your current company. Was there a particular incident that you can recall, for example, that you were trying to help prevent other organizations from dealing with?

J: Happy to. The era when my co-founder Tyler and I got into the software game was between 2010 and 2020, which we describe as a renaissance era for dev tools. As a result, if you're on an engineering team, life has gotten really good for you. You've got dev ops and agile and automation and CI/CD. Every single day, there's something that's coming out that's helping you be faster, more efficient, get code out and get value to customers faster and faster.

The realization that we both came to from different ends of the spectrum — he's on the technical side, and I'm on the product and marketing side — is that no one was very thoughtful between 2010 and 2020 on the impact that this rapid software development has on the rest of the organization. If you’re shipping code, now multiple times a day, what does that mean for your sales, support, and customer success managers, and ultimately, your end user? Because that's really who you’re there to serve.

Over time, we saw that problem get worse and worse — the complete misalignment between the non-technical half of your organization, in terms of knowing what was coming, when, and what they should be communicating to customers.

There was a catalyzing moment for us. The universe basically sent a sign. Tyler had left Atlassian, where we were both working at the time to start LaunchNotes. We were grabbing lunch one day, and he was catching me up on what he was working on. I led product marketing at the time for the JIRA business unit and for Atlassian. After lunch, I went back to the office for our biweekly product roadmap review. We would sit down my entire team in San Francisco, all the product folks on the JIRA team, and a lot of the engineers, and we would run through the roadmap. All the PMs would talk about everything that they were working on, everything that they had shipped that very afternoon. Of course, the entire point of the call was to drive alignment and make sure that everyone, specifically my team, which was responsible for the release, and the communication around the release, knew what was coming.

We were watching a demo of a feature that in the two-week span since our last meeting had been designed, QA’ed, and rolled out. And no one on my team even knew what had happened. This was a feature that we could have made some made some noise about. It was significant. And it was a very bittersweet moment: one the one hand, we had finally unlocked the team to be able to ship value that quickly. That's a great sign for the organization. However, it was completely hampering my team's ability to do their job.

This was a few hours after I'd had lunch with Tyler, when we were talking about this problem. I thought, this must be a sign. So wrote him an email that night and said, Hey, I've seen this problem get worse and worse. And now I'm feeling it acutely. So if there's room for me on board, let's go solve it together. That's how things got started.

A: So you said I'm committed now wholeheartedly, emotionally, no going back. Tell us, why is this a problem? Our teams have been building and shipping software for decades. Why is it become such an acute pain point right now?

J: The first thing is just as I mentioned, the rise of all these tools that are unlocking R&D teams to be faster and more efficient, which, again, for the end user can be really good. What added more gasoline to the problem was the move to remote and distributed work. It’s already tough to coordinate if you work in an organization where different teams sit on different floors, or you've got a few different offices across the country or the world. You put the COVID pandemic on top of this, where everyone started working from home, and people started living all over the world wherever they wanted. That was the straw that broke the camel's back. When everyone is remote, they're on different time zones. How do you know who's working on what, and specifically in today's age, when things change so quickly, so your weekly update meetings are no longer going to be any use?

A:  What do you notice are the biggest mistakes that teams make when they're releasing new features?

J: The first one would be not involving customer-facing teams soon enough. We had a rule on my team at Atlassian: in their kickoffs, at the beginning of a new agile sprint, I wanted one of my PMs to be there at the table, to know what was being worked on. I don't think it's malicious by any means. But there's still this walled garden, and people get stuff thrown over at the last minute. LaunchNotes has a built-in roadmap functionality to make everyone aware of what’s in the next release. Whether it's an internal roadmap or an external roadmap, you can share different versions based on the audience that you want to communicate with, since not everyone needs to see everything. There should be a way that is worked into your product development lifecycle that proactively communicates, hey, this is where this feature is in the process.

We're big on collecting feedback, soliciting feedback on a regular basis from customers, from internal teams. But we often talk to customers about turning things from a monologue into a dialogue. It builds trust and leads to better product outcomes. As things are coming down the pipeline, it allows your customer facing teams to ask questions, and there's someone there to answer those questions. It’s about collecting feedback, having a way to synthesize that feedback, and giving people the opportunity to ask questions, give their thoughts, and give praise.

A:  Those big mistakes that you mentioned really resonate with me. I think so often customer support teams are left in the dark about some of the critical issues. And then when the product is released, they're often on the front lines of defending why the product was released in this particular way. And also, they're helping to figure out, what's a feature versus a bug, and are generally swamped and maybe not as well educated about how the new feature works as they could be. I've also noticed many situations where customer facing folks, whether it's sales, customer success, or customer support, they're held accountable by their customers for knowing what the future product roadmap is, but even if they were equipped with knowledge about it, that knowledge might be in the form of an outdated PowerPoint deck that happens to be living on their laptop, and then they're at risk of communicating the wrong deadline. Also, often PowerPoint isn’t a particularly good medium for describing a new feature. It might include some flashy terminology and screenshots, but probably doesn't explain things at the level of depth that you might in some more purpose-built platform. So yes, I noticed these mistakes, and I imagine many of the people listening to this podcast are thinking of their horror stories.

J: I love what you said about customer success and support. We actually just today released the new version of our feedback collector. One of the things that we added is the ability for customer success managers to privately share a roadmap as they're reviewing what's coming with the customers they support. Then we added the ability for that customer success or customer support person to be able to submit feedback on behalf of their customer. So as you're walking the customer through the roadmap, if they have feedback, or thoughts or questions they can submit on behalf of the customer, which puts them in a position of empowerment, to be able to better serve their customers versus, as you say, being behind the eight ball, and the customer feels like they weren't enabled. They don't know what's happening, they're frustrated, and the support or success people are equally frustrated because they didn't know enough, either.

A: We've talked about what mistakes you can make when releasing a new feature. One question that I get a lot from founders that I work with is, what does a best-in-class release process look like? What does it look like in your opinion?

J: Philosophically, there's a few different things that people should be thoughtful about when building a release process or trying to modify a current one. The first is an idea that we talked to a lot of our customers and prospective customers about, that change is a constant, especially in today's SaaS world. That's the reason that the SaaS world exists: so you can be continually updating, improving, fixing on a regular basis. But at the same time, there’s a desire to be like Steve Jobs — to have big releases, stand up on stage, and unveil something that's been worked on for months or years. I understand that, coming from a product marketing background. However, that's not practical in today's world. Getting people in the mindset of, let's just continually talk to customers about the value that we're shipping on a regular cadence, and we don’t necessarily have to have huge marketing moments every month or every week. It's just about the value that you've created. There’s a cycle of: “change that’s coming”, “change that’s happening”, and “change that happened”. That's a cycle that's going to constantly repeat.

The second thing that we often talk to teams about in terms of a best-in-class release process: consistency. Especially in the product marketing community, there's a constant conversation around, what's the right cadence? People say, How often should we be releasing stuff? Weekly, biweekly, monthly? The answer is, it completely depends on what kind of software you have, your maturity, and all sorts of factors. What I encourage people to do is not think about cadence, but think about consistency. Humans are creatures of habit. We like consistency. We like to be able to know when to expect something. So, choose the consistent basis that works for your team, whether that's weekly, monthly, whatever it is. The important thing is that you're continuously communicating with customers and showing them the value of what you're creating for them.

The third thing is — and this is a core value of ours — transparency. Obviously Atlassian is a big champion of a building in the open, and open teamwork. In the year 2022, there's a lot of software out there, everyone's building quickly. It's very competitive. So I say, use transparency to your advantage. If you don't share your roadmap, someone else will, and whoever shares it first, everyone else is going to be chasing them. There's a lot of heartburn around sharing roadmap. But I think in great release cycles, you can see the change that's coming, you can excite users about it, you can give them a sneak peek. Think about, how do you use transparency to your advantage? You're doing all this great work behind the scenes, so don't have your engineers working on something for a month and then just have it pop up. Because you've just wasted a month to get users excited about it and collect their feedback on it.

A: A great list. One of the questions that I get a lot is how to ensure that go-to-market teams are able to provide ideas and feedback on the product roadmap, and specifically upcoming feature releases before critical decisions are made by the product team. You can imagine that these questions are coming from go-to-market leaders that want to make sure they have input, as well as from product teams that want to show that they're being really thoughtful partners to the customer-facing folks, and that they are making the right decision. So I'm wondering if you've noticed best in class companies using certain recurring forums between go-to-market folks and product teams, or perhaps other types of communication that ensure that go-to-market teams can be involved early in the decision making process?

J:  Absolutely. It's one of the reasons why we built the LaunchNotes roadmaps to be internal-facing. One of the things I've seen some of our customers do with great success is build specific milestones into the process for incorporating go-to-market teams’ feedback. They have a column that says, “ready for review by go-to-market.” So you, the go-to-market team, have the next 48 hours to look at what we've done and offer feedback on. They’re very deliberate about it. We've seen at least two or three teams do this with pretty great success.

A: Those are great ideas. I know that you've spoken with probably hundreds, maybe 1000s of product teams. I'd love to know from your perspective, what's the greatest misconception that product teams have about the release process?

J: If I had to pick one — and I don't think this is just related to product, I think product marketing is equally as guilty of this — it’s that a spray-and-pray approach is going to work. I think there's this idea of hey, something is released. Let's just go down the checklist. Let's just get an email out, throw it up on the blog, put some release notes in Zendesk, and call it a day. And we assume that everyone is going to visit one of those three mediums. But you're likely reaching 10, maybe 20% of your users when you do that. Repetition is important. We encourage people to do a weekly launch, but then also do a monthly roll-up, and a quarterly roll-up. Even if you're tweeting about it, putting it up on LinkedIn, do a couple reminders, do it several times, do follow-on content, but just on launch day, just kind of pressing all the buttons and hoping that everyone is gonna see what you've done — it's just not going to happen for sure that way. That's something that I think is a pretty big misconception that's pretty industry wide.

A: I know a lot of founders who are gearing up for their big launch announcements, so I'm sure they're listening very closely. I've learned a lot from this conversation. Jake, thanks so much for joining us.

J: Thank you. This was a lot of fun. I appreciate it.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

I have a hunch that many go-to-market folks in the SaaS world will transition into Web3 companies at some point in their careers. But what does “go-to-market” mean at a Web3 company? If you’re in marketing, sales, customer success, or business development, it’s likely that your skills will be relevant, but you’ll probably have to learn new ones, too.

In this podcast episode, I sat down with Jenn Kalidoss, who leads Product and Go-to-Market at Syndicate. We discussed:

* The value proposition of her company’s product, and how it differs from Web2 alternatives

* What metrics she focuses on

* Which job functions translate well from Web2 to Web3, and which don’t

I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about.

* Workstream: Head of People

* Kingdom Supercultures: Head of People

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* LaunchNotes: Director of Engineering

* Palette: Product Marketing / Head of marketing (US/Europe)

* Guide: Head of Marketing

Transcript:

Allison: Jenn, I'm so excited to have you on the podcast today. I think you come with a wealth of information about emerging go-to-market efforts in Web3 companies. And I think the audience is going to benefit a lot from learning about your expertise.

Jenn: Allison, thank you so much for having me here. I'm excited to talk about all things Syndicate and beyond.

A: To start, can you tell us about your background and how you got into Web3?

J: I actually grew up and did my college in electrical engineering in a very small town in South India where access to internet or most worldly information was very limited. I heard the word Bitcoin for the first time when I came to the US in 2012, mostly from my coworkers at the time. I researched about Bitcoin and learned about how it offers access to a financial system with no censorship, and for a person whose family had trouble for almost a decade in trying to obtain a simple state ID card with which you can open a bank account, it was intriguing to me. I ended up reading the white paper, but most of it went completely over my head. I understood the math aspects of it, but not the cryptography pieces. And then when I joined Stanford in 2013 to pursue my master's, we just mostly focused on semiconductor physics.

I tried to get back to that white paper and understand also what is cryptography, what is going on in that world? And I found it very fascinating mainly because the math was so elegant, but also a whole industry was sprouting at the time. So toward the end of my master, I was pretty convinced I wanted to work in security but did not have the background for it. Because I had only snuck into a few CS classes to understand what cryptography was. Luckily I was hired by Hewlett Packard Enterprise to be a hardware design engineer for their next-generation hardware security module, which is similar to a hardware wallet, but it's a server version of it, which is mostly used by banks and government agencies for key management encryption systems.

During my time there at Hewlett Packard, I got to again hear about Bitcoin and Ethereum and also invest in them, because I started to get a paycheck, as well as Lightcoin and others. And our CTO at the time was very excited about the prospects of Bitcoin and the whole crypto industry in general. He would host a lot of brown bag lunches to teach folks what it was all about. That led me to learn more about Solidity and build decentralized apps on Ethereum, which was really fun. It was through a Stanford class on how to build Dapps that I was introduced to the CTO of Bitski, and I ended up leading Security & Custody there, before I went to GSB to do my MBA. Finally, while at GSB, I ended up leading the Stanford Blockchain Club on campus and also worked as an early stage VC in the FinTech and crypto space. I also ended up helping FinTech Collective put their current crypto fund together.

A: Can you tell us what is Syndicate and what does it offer?

J: Syndicate is a decentralized investing protocol and social network. We are on a mission to revolutionize investing by changing how communities and capital work together in using Web3 technologies. Our first product, we call it the Web3 investment club. It brings a group of people together to pool their capital and make investments together in Web3 assets like ERC-20 tokens, NFTs, and even Web3 startups. Investment clubs are a relatively recent way of investing. It brings people to the table on an equal footing and allows folks to learn together about investing in a more casual setting. Because the regulatory and legal lift is pretty low compared to if you were to start your own venture fund or any other investment, it lowers the barrier to investing and makes it fun.

Especially with the investment clubs, given that crypto is a relatively new asset class, it gives people the chance to come by NFTs or tokens together, learn about crypto, and then take it to the next step. Our current product is completely self-serve, meaning anyone can create an investment club in a couple of minutes, and unless folks who create investment clubs tell us that they actually created those clubs, Syndicate will not know that you've created an investment club. We just actually crossed a thousand clubs on our protocol as of Monday [a few weeks ago, when this podcast was recorded].

A: Amazing. Can you describe more about the value proposition to your customers?

J: We make it incredibly easy to spin up an on-chain investing DAO. Financial capital flow in an organization is probably one of the most important pieces and we try to make it as easy as possible, whether it is to support forms of investments on chain or off chain, how you do incentives for contributors, how do you do returns for your LPs and such? We help with all of that cap table management and distributions.

A: You've spoken a little bit about the use cases for using Syndicate, but can you talk about how you would categorize the different types of customers that you have now, why they're using it and then perhaps in the future, what might be some additional use cases that you would take on?

J: We actually have a wide range of customers among direct consumers. We are looking at friend groups coming together to buy an NFT that they just recently saw on Twitter, to investment firms who want to carve out a portion of their fund and put it towards very specific goals like investing in women-led companies. And they want to create the community around that goal where the community can decide how they disperse the capital, and the community itself can take that capital and go disperse it on their behalf. So there are so many different structures that we can support. We also see a lot of solo GPs who want to co-invest with other GPs. We also see mission-based collectives, like climate-based DAOs. We have founder investing groups and such. So our customer segmentation covers both B2C and B2B. And we support use cases that range from the music industry, where they want to open source the assets that music producers have, to carbon credits, to real estate, making it more accessible for renters and owners to participate in that economy.

A: Can you talk a little bit about why it's important to do this on-chain or in a Web3 context and relatedly, why wouldn't AngelList or Assure be sufficient for these use cases?

J: Pooling and allocating capital is incredibly easy and cheap on-chain, depending on which blockchain you use. Sometimes Ethereum’s gas fees are high, but you know, even when their gas fees are high compared to current Web2 solutions, it's still a much cheaper and easier way to transact. Today, if you want to spin up an SPV or investment, some of the web solutions charge you anywhere between $8K to a few tens of thousands of dollars, and we are working to reduce the cost and complexity of it. Crypto is inherently composable. We are trying to work towards a system of solutions that can be put together, where ultimately to the consumer it's cheaper and faster. And it's so nimble that you don't even have to think twice about the steps that you have to go through in creating some of these investment vehicles.

Additionally, it also enables innovative ways of investing and permissioning into certain assets like NFTs, but also using NFTs for permissioning who gets to participate in which vehicle.

And lastly, I would say people also want on-chain reputation, so they can unlock new opportunities and access in a more decentralized manner. It would be great if folks in the U.S. can co-invest in a company or asset somewhere in Asia or Africa with an investor there who has a similar risk appetite. And you're able to get that information in a more decentralized manner, as opposed to you just being in your own cluster. And if you ever want to invest in other jurisdictions, you have to have a foot there. It's quite complicated how it works today.

We want to break down those barriers in terms of how it compares to AngelList and Assure. Investing on Web3 inherently requires a Web3 infrastructure, from using Multi-Sig, to how do you buy NFTs? Because for you to buy NFTs, you have to have a wallet, and you have to interact with a contract and a protocol. And just the bridge between the Web2 world and Web3 world becomes very clunky from a user experience perspective. Now that more people are warming up to the idea of a wallet and how to use one, we believe that we do need that Web3 infrastructure to make it very seamless. And we do have a lot of customers who come and tell us, I just want to invest in equity deals, why should I choose Syndicate over AngelList or Assure? And we can tell them that AngelList and Azure are powerful platforms to invest in non-Web3 assets, like equities, as of today. And they come with a lot of services too. Also, if your LP base mostly deals with bank transfers and not crypto or stablecoins, it is better to use those platforms. But if you want to have specific access, if your LP base wants to have access to certain assets that you are not able to do on AngelList, we say, come to us and we'll help you make that happen. And slowly also build your on-chain reputation because down the line, that's going to be important for you to tell a story about what kind of an investor you are.

A: Switching gears a bit. Can you tell us about your particular role at Syndicate?

J: Currently I lead go-to-market and growth at Syndicate. That covers community, sales, marketing, partnerships, integrations, and customer success as well.

A: What are your KPIs when you think about running those teams?

J: Some of our current KPIs are a bit primitive, as we are still developing them. Our product has been out for about three months now. The most important KPI that we look at is the number of clubs created, because that tell us how our customers are driving value, as well as the conversion rate. The way we measure conversion rate is how many clubs have at least one deposit, over the total number of clubs created. And the reason that is important to us is when you come on Syndicate and you spin up an investment club, it takes you anywhere between like $30 to maybe $150 to spin up something in terms of gas fees.

For some folks that might be a high enough cost that they will see through the rest of the steps. And for some folks, especially within the Web3 community, that actually is not that high of a cost because they are spending similar or more to buy an NFT. And so when a club has their first deposit, it shows that the person who created the club, who can be the admin of the club, has taken the steps in terms of the documentation and thinking through the strategy of what that club is going to be used for. And there is higher intent to utilize the club. It's the way it's supposed to be utilized. And so that conversion rate metric is very important to us.

We are hoping our next step would be to measure the number of external transactions, which could indicate investments being made out of the club. And that conversion rate would be important to us too.

We also measure AUM in our protocol, how many unique wallet addresses are connected to our web app and transact on our protocol, the number of median club members, and lastly, community engagement and retention through Discord and Twitter is also very, very important to us.

A: Can you describe your pricing model in more depth? How do you make money?

J: Syndicate does not make money. We are intentional about our monetization model in that, one, we are experimenting and thinking through ideas. And two, we believe that a lot of the value accrual will happen on the social layer. And so we are trying to figure out what monetization on that layer could look like, because we also want to only make money if our users make money, and we want to align our incentives with our users’ incentives.

So for that reason, we've been quite slow and intentional in thinking through monetization. Now, outside of that, we also provide certain services in partnership with companies like Doola. And we will be having a few other partnerships coming along as well, where if they provide fund admin or entity creation services, users will have to pay for that. And through that, we might get a small chunk of revenue, but that is not our main revenue model.

A: How do you support your customers?

J: If they reach out to us through Discord, Twitter, or any other means to reach out to Syndicate, we actually do a lot of superhuman-style onboarding calls to understand, one, what they're trying to accomplish and how they can use Syndicate, because we have a lot of customers who have a goal in mind. But they will email us saying, I want to create an evergreen structure fund. How can I do that? It is important for us to dig deeper than that, because in most cases they can use the current structure. They're just thinking of a couple additional features that perhaps we can enable in a custom way, but because the way they think about it is perhaps like closer to, for example, an evergreen fund, they use terms like that and they want to get that started, but they often lack the understanding that there's a lot of legal compliance and regulatory things that they have to do when they create a fund structure like that. And ultimately they may not even need that. And so for us, it's very important to understand what is it that they exactly want to accomplish and what is it that they need. So we jump on a lot of calls. Probably most of my days go into talking to customers.

We also share content on how to think through some of the strategies and examples of how our other customers have done it. We share legal templates and other templates. We also talk to them about how they can use other Web3 tools in addition to Syndicate to make their ultimate vision come true.

The last thing we also do in terms of like supporting them, we are open to a lot of custom work as well. For example, someone would reach out to us saying, Hey, we want to create an investing DAO, but before that, we actually want to create a membership tier. And can you guys help us create membership NFTs or things like that? And we would say yes, and, and that is good for us because we then get to test a potential product as well and validate if it is useful for the customer or not as well. So those are some of the ways in which we support them. Our channels include email, Twitter, Discord, even podcasts like this. We get a lot of requests and we intently respond to all of them.

A: What job functions do you think translate well from Web2 to Web3?

J: I would say a lot of engineering, because we do need backend engineers, frontend engineers, engineering managers and such design teams, actually product and brand. Web3 brand is a little bit different, but you can learn quickly. A lot of operations and people operations.

I would say genuinely, if you enjoy learning new things and quickly testing out and trying, folks will thrive in the Web3 space. There is a lot of need for talent in different verticals as well, from legal to regulatory, compliance and other verticals as well.

A: If I'm a go to market person in a Web2 context, chances are I'm in one of four functions: I'm in marketing, sales, customer success, or operations. Those four job functions, what is their definition in a Web3 context? What does marketing mean? What does sales mean? What does customer success mean, and ops as well?

J: Marketing means Twitter. I am joking, but not really. At least within Syndicate, marketing covers all of product marketing and positioning as well as content marketing. We use our website, SEO, Twitter presence, word of mouth and web communities, PR blog posts, NFTs — a lot of content-oriented methods.

Also, could we drop an NFT to our early supporter and get them incentivized? If we had tokens, our go-to-market and marketing would look very different as well. Can we airdrop tokens to acquire and retain customers.

I would say in some ways, a lot of the Web2 marketing skills still very much apply. It's just that there are additional things that we have to look into in the Web3 space, and most efforts are very grassroots.

If someone were to post on Twitter saying, I am thinking about creating an investing DAO, what should I do? Syndicate should be there being like, check us out. Those kinds of things too are important under the marketing umbrella.

A: How do you expect your organization is going to evolve over time? And who do you plan to hire in the future?

J: We have a lot of potential to grow our internal teams. We haven't opened up our protocol yet to the public, but we will also have a developer community. In the last year or two we've been growing and have been hiring a lot of talented people. We do a lot of opportunistic hires actually. And so if anyone who's listening to the podcast is excited on the engineering, design, product, and external business operations side, please reach out to us.

I actually got this job by DMing Syndicate’s Twitter account. So any interest, even if people were to come and say like, Hey, I've done these kinds of marketing, I'm excited about Syndicate, is there any way I can contribute? Chances are there are a lot of ways, so definitely reach out.

A: Final question for you. What tips would you have for Web2 people looking to get into Web3?

J: Use the product. When we are trying to pivot into a new vertical industry, we could often have this notion that, oh, let me read blog posts. Let me talk to a lot of people and I'll have a better understanding. And then perhaps I'll try to pivot into it. Web3 behaves a little bit differently. You gotta put money where your mouth is. So even if you have a few hundred dollars and just play around with it, that is the education piece for Web3. Folks will say, Ethereum was too expensive to play around with, which is great because there are other chains that are cheaper. And if you learn how to interact with other chains, you can easily know how to interact with Ethereum. And so it actually gives you more chances to learn crypto pretty deeply. So go buy that NFT. Even if you are not a big fan of NFTs, go buy a token on a decentralized exchange. Break out of your Coinbase or other centralized exchange account. Spread your wings.

A: Spread your wings. That's a great note to end on. Thank you so much, Jenn, for joining us today.

J: Thank you Allison for having me. This was fun.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

I’m now including lightly edited transcripts in these podcast newsletters. Scroll down if you’d rather read than listen!

So you’re a COO or Head of Operations. What does it mean to perform well in the role?

In this fireside chat for On Deck’s Strategy and Operations program, with program director Fadi Hindi as my interviewer, I spoke about:

* What makes a strong COO?

* What should be your self-onboarding plan when joining a company as COO — and if you’re a founder, what should you expect from that new COO?

* How can you run a top-notch OKR process to help all functions work well together?

See the lightly edited transcript of the podcast below if you’d rather read than listen. I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles:

As always, I’ll share some leadership roles at companies that I’m excited about:

* Workstream:

* Head of People

* Head of Content Marketing (Utah or SF) 

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* LaunchNotes:

* Customer Success Team Lead

* Director of Engineering

* Palette: Product Marketing / Head of marketing (US/Europe)

* Guide: Marketing leader

Transcript:

Fadi: Super excited to do our first Fireside Chat. I am honored to be here with Allison Pickens, and I'm not even going to try to give her a background because I won't do it justice. So wanted to really kick things off by having Allison introduce herself to everybody. And then we'll dive into the topic of the role, the COO and just everything that's been happening on that. Allison, please take it away and tell us a little bit more about yourself.

Allison: Sure. Thanks everyone for having me here today. I know I'm surrounded now by some amazing COOs and happy to impart what I learned from my experience at Gainsight, my experience working with a lot of other companies, but also excited to see what you're seeing in your roles, and we can learn from each other.

As for my background, my last role was COO at Gainsight. I joined when we had about a million in ARR. So it was very small. Before that I worked in private equity investing and at Bain Capital, and the venture arm had led an early funding round in Gainsight. That's primarily how I got to know the CEO there. I joined in a really generalist capacity, a number-two type role. My title changed three times in the first three months. Happy to talk through all of that. But over the next six years I built out dozens of functions. I ended up leaving when we had about 85 million in ARR.

I also spent a lot of time on our thought leadership content. Since you might know Gainsight as a customer success software company, we were pursuing this category creation motion. And that meant having to become the focal point of a lot of discussion about how to drive net dollar attention, because customer success management was one of the teams that I was building over the years. The team ended up becoming this kind of incubator of best practices. And of course we were working with all of our customers who were in turn customer success teams. So we ended up building a lot of best practices about the topic and building a lot of community around that. That work the content and best practices led me to advise many B2B SaaS founders who were folks that we were trying to sell to.

And that led me to join a few boards. I've been on four boards, three private, one public. Currently I'm on the board of dbt labs, which is a data transformation company. And I'm also on the board of a public company called Commvault, which is in the data management data backup and recovery phase. It's fun to have seen the venture side and also seen the public side. And what's always fascinating is the public companies want to learn to be like smaller companies — be more nimble and innovative — and small companies want to become big companies. There tends to be a lot more crossover than you might expect.

After Gainsight, I wanted to spend all my time with founders. and I was trying to figure out a way to build a business model around that. I realized that if I raised a venture fund and I could co-invest alongside lead VCs, then I could formalize relationships with founders that I wanted to work with. So I did that and over the past year and a half I have invested in a number of B2B SaaS companies across stages, everything from pre-seed to pre-IPO. And I feel like I have amazing job, since I get to work with like incredible founders, every day, all day. And particularly this maybe goes back to our conversation, kind of serve as — I wouldn't quite call it a fractional COO because I'm not a service provider, but I call it a fractional COO thought partner, to many founders. And yeah, I’m excited to be here today and chat with you all.

F: Awesome. Well, I hope this intro allowed everyone to see the reason why we asked Allison to come in, so super excited to have her here and have this conversation and just wanted to preface for everyone. We will make sure there's plenty of time for live Q&A. So I'll kind of get started with some preset questions that will be super applicable to what you all wanted to learn. And then we'll make sure to save at least 30 minutes at the end for you all to do some live Q&A with Allison. Well, my first question already kind of got answers in your background about kind of how you got into the Gainsight role. Would love to kind of dive in and just talk about, in your opinion, based on your experience thus far, what traits and behaviors make a good COO?

A: I think the first thing to mention is that there are many different types of COO roles and depending on where you live in the country, what kind of business that you're supporting and especially what kind of CEO are you working with, the role can vary tremendously. I tend to see there being four types of COO roles. One tends to be a chief of staff type role, which is kind of the role that I entered into when I first joined Gainsight. So that’s type one, the chief of staff role. And it tends to be a generalist problem solver, an extension of the CEO. I actually recommend this to a lot of my founders, that they hire someone like this in the early days who can help them tackle more special projects, launch more initiatives and figure things out around the company.

There's a second type of a COO role, which I think of as a “CFO-Plus”. I tend to see this a lot in New York City. For some reason, that's a common role there. Maybe it has to do with e-commerce businesses or just the industries that are there. But it's often someone who grew up in finance and they're taking on more cross functional responsibilities over time. They're helping to manage certain functions that might have been called staff functions in an earlier era — finance, legal, HR, BizOps, and they're helping to serve as the glue across functions in their organization.

The third type of COO that I've observed tends to be a CRO. They might have the title CRO or COO, and typically they are managing the journey for customers and therefore interactions with all different customer facing functions. So they're managing marketing, sales, customer success. If they're a CRO, they may or may not manage marketing. That might be something different, but typically it's everyone involved in the customer journey, and there might be professional services or support that's added to that.

Then finally the fourth type of COO role tends to be a President, someone who is truly running the business, and they might have all the functions that the chief journey officer or chief revenue officer had, plus maybe people and ops or corporate development. Often it's everything except product and engineering.

So, going back to the question that Fadi was asking, I think the skills that are required for the COO role tend to depend on what type you are. And based on my description, you could probably start to imagine what the skills are.

I would say that as a general rule, there are certain skills that are useful across these. I think one is non-technical skills, like gaining broad-based buy-in across employees for initiatives that you're launching. Resolving conflict among diverse stakeholders, handling team member concerns and being able to gather buy-in, gather feedback, communicate decisions, help people understand why their point of view is valid, but may not be taken into account or help people understand why you decided with one point of view versus another. I think there's a lot of general communication and engagement that tends to be a big part of this.

I'd say, all four roles tend to involve creating OKRs or being really involved in the OKR process one way or another. So I think becoming an expert on that is probably a good idea.

And then, generally learning how to manage a really close, trusting relationship with a CEO who is typically the founder and often very product-oriented, vision-oriented, focused on community, evangelism, and is less interested in running operations, which is course why they hired you.

F: Super helpful. You actually even got into something you want to reference, which was you wrote this beautiful Substack article about the rise of the role, and you kind of referenced a little bit about it right now by describing the four types in your opinion. But maybe you could deep dive into why in the last five to 10 years this role has been on a rise and why are we seeing more people being attracted to bringing on a COO? This is super interesting.

A: Sure. I think there are sort of two sets of reasons. The first set has to do with founders staying in their roles much longer than they used to. 10 years ago or so 15 years ago, it was really common for a founder to start the company, run it for a couple years, get to some product market fit. And then a professional CEO would be brought in. That no longer happens, for a few reasons. One is that founders have much more power than they used to have. There's an abundance of capital even with the market downturn and valuations going down, there's still a lot of deals getting done. And there's the ecosystem is flush with all the capital that VCs had been raising particularly over the last year. [Allison update: This podcast was recorded several weeks ago; the pace of deals has slowed down since then, and some VCs are pausing their investing, particularly at the growth stage. How that translates into the founder-VC power dynamic has yet to be seen…] It'll take a while for that capital to, I think work its way through the system. If you're raising from a VC as a founder, that VC is very eager for you to accept them on your cap table. And the last thing they want to do is appear to be un-founder-friendly, like they're going to replace you at some point. And actually they may not even take a board seat even at series A or sometimes B or a lot of the time these investors are much more hands-off, trying to be much more supportive to founders.

Also I think software companies in particular are much more product-led than they used to be. Product is important, not only for driving the value proposition, but also for the growth strategy, for example, in product-led growth companies. The founder skillset is often product oriented. It makes sense for them to continue to run the company.

And then, finally I think a lot of people through making mistakes have realized that if you replace the founder, you're removing the person whose spirit has infused the organization. And the organization can suffer from a deficit of purpose and mission. And it becomes this executional machine that people may not be inspired to work at, customers may not be inspired by, and it loses its essence.

So for all those reasons, founders are staying in their seats much longer and that means there still needs to be someone at the company that's helping to run things, but that person is not going to be the CEO, it's going to be someone else. It opens up the possibility for a COO role being much more essential.

And then, there's another category of reasons for the rise of the COO role which has to do with things not related to the product. For example, to run an effective go to market strategy nowadays, you need to be able to align all functions. They can't operate in silos anymore, especially if you're at a PLG company. All these organizations need to be able to work super closely together. It requires someone who can help orchestrate that very nuanced ecosystem.

People are moving away from the vision of a company as being this sort of militaristic army-like structure, which is previously what had informed corporate hierarchy in the fifties. Now people see organizations as being flatter and much more focused on how people collaborate, how they depend on each other, how they work together to achieve goals. That might be goals in common as opposed to goals that only particular functions own in silo.

I think the final thing is that companies are growing faster than they used to. It used to be triple, triple, triple, double, double, or triple, triple, double, double, double. Now it's quintuple, quadruple, triple... That's partly because the product is driving growth, but you still have people and it's still hard for people to experience change. Arguably it's even harder when the change is more rapid, and you need a leader who can help orchestrate that change management.

Those are the reasons I see why the COO role has become a lot more popular.

F: Cool, super helpful. Now we learned the landscape and how it has evolved over time, different roles and different stages, why you need a certain type of COO. Segueing into, “you are now in the role of COO,” I would love to understand from you, when you onboard onto one of these four categories of COOs and you're at this company now, what are some strategies or approaches you've built in your career that says, this is the best way to onboard as a new COO?

A: I think listening is the most important part of COO onboarding. It can be tempting to come in and immediately try to prove your value, but it's hard to know what counts as value if you don't know your context. So I find that a lot of COOs come in and do a listening tour. They spend tons of time with the CEO, digesting everything that's in the CEO's brain. That's important partly so you can make the right decisions as COO. It's also really important to lay the groundwork for that trusting relationship that I mentioned earlier. You want to understand how this person thinks, what their hunches are, what they enjoy, what they prefer working on and what they're expecting from you. And then, over time you can start to reciprocate and share your points of view and bounce ideas around it. It lays the groundwork for a good relationship.

I also recommend listening to your board. Meeting with the individual board members, hearing what their views are on the company, why they invested, what their theses were, what were they expecting would happen, and did the company to fulfill those expectations? What do they think are the biggest challenges and opportunities going forward? I'd make sure when you're meeting with these board members that you've, of course, received permission from the founder. Board relationships can be sometimes a little bit sensitive from the founder's perspective, even in a situation where they're in the power seat. It's important to bring the CEO along your journey of meeting with different board members. But I do think getting their perspective is valuable.

It also, again, helps lay the groundwork for your relationships with board members. So that in future board meetings, when you're presenting, you feel more comfortable. Also, you know what to speak to because you have in mind what each of these people is looking for from you.

And then of course, arguably the most important listening that you're doing is the listening to team members. So you might set up, depending on how big the company is, focus groups of people, perhaps by function or by topic area or by location. If you have offices in different places — a lot of companies are remote first nowadays, so my guess is that's probably less common — but again it depends on the company. I think what you want to clarify in advance of those is that you are here to learn, that these folks have experience in this industry and at this company, and that's very valuable.

You want to hear what's going well, what's not going well, how can you make people's lives easier? How can you grease the wheel? How can you make sure that there's better collaboration at the company? And then, once you've listened, you want to play back what you've heard. That's true for any stakeholder that you meet with, but especially team members really value when they know that you've heard them. You don't have to say necessarily, "Here's what I'm going to do about what you talked about," but it is valuable to say, "Here's what I heard from you. And in the coming months as I get up to speed, I'm going to be thinking through how to prioritize these things. And you'll start to understand the prioritization as we, for example, roll out our OKR process or hone our OKR process."

F: I guess once your listening is done, you've gathered all these data points that you've gathered from the board, the CEO and different stakeholders, what do you typically do with it? Do you have a set process or a strategy for driving execution? Oftentimes what we hear is people are like, "I'm constantly fighting fires." There's always so much to work on, but then how do you create the right focus areas or priorities so that you know for a fact, these are the five buckets I need to focus on for the next 90 days, six months, 12 months.

A: Yeah. I think the OKR process is the vehicle for prioritizing. OKRs are objectives and key results. I think of the objective as being the spirit that's behind the metric. Why does this metric matter? Why are you doing this? And the “why” is really important because for so many reasons, it helps you understand the prioritization. It helps motivate people to achieve goals. Some people are very oriented toward metrics, some people are not as excited at the end of the day if they achieve a number or not. The objective can be an inspiring force within the company.

What you want is three to five of these OKRs across the company. Eventually as your OKR process becomes more mature, you can trickle down — or up, depending on your view of your organization — but basically those OKRs should translate into goals that individual people are working on. In terms of how to translate the feedback that you're hearing into OKRs, it's useful to involve everybody in that process, in some form or another.

For example, you are gathering your leadership team, plus maybe an extended group and maybe an offsite at a key point in the quarter, and together you are iterating on a framework that you and the CEO put together for an initial draft of OKRs based on what you've heard in the listening tour. There's kind of a sequential iteration process that you can follow and eventually you'll want to communicate that set of priorities to your company in an all hands. And there might be an initial period where anyone a the company can give feedback and you can have a last chance for anyone to comment. And then, a couple days later you say, "Okay, great. This is what we rolled out. This is filed for the quarter."

Then you've got your cadence for tracking against those things. Eventually, you'll want to make this an annual process, but assuming that you are coming into the company midyear, thinking about the next quarter is probably a good idea.

F: Once OKRs are in production, there seems to be this natural tension between teams, when it comes to priorities. How do you navigate polarities with your organization? Typically, what I've seen is, there's tension between Biz Dev and Product, or Marketing and Finance, for example. In your experience, how do you navigate this tension?

A: At the end of the day, it's impossible to avoid tension. I do think that's sort of a fact of running a company, but the more aligned that you can be as a company the better. And I certainly think that for the COO role, one of the measures of success of the COO is how aligned are people. So it's a great question.

There are a few ways that I've seen people try to mitigate tension or prevent it from happening. One is when you're designing OKRs, it's important to ensure that, if you're signing someone up for OKR, that they had the opportunity to say, "It's going to be difficult for me to achieve this OKR unless another function does certain things." We're all clients of each other's work at the end of the day.

If marketing, as you noted, is responsible for a certain goal and they need some input from finance in order to achieve that, or maybe they need help from product in order to make sure that a launch is successful, that's got to be built into OKR. So in this OKR process, you're mapping out all the dependencies and acknowledging upfront when people are going to be depending on each other.

Another way to ensure alignment is to rethink your compensation model. I'm used to working at companies and interacting with companies where every function has its own goal that it's responsible for. Sales has quota attainment, and marketing has a pipeline goal, and customer success has a retention goal, and their compensation is based on that.

I actually think — and initially when I started saying this, it was controversial, but now I've noticed a couple companies that are very successful doing this — I'm a big believer that basically everyone at the company should be paid a base salary, and that bonuses are distracting and often skew behaviors in strange ways. At the end of the day, we're all corporate citizens, or citizens of this organization. We're all on a mission together. From a financial perspective, our job at the end of the day is to help drive the valuation of this company. If you orient people toward being more mission driven in that way together, everyone is in the same boat, we're just in different roles, you set the groundwork for alignment in a much more robust, foundational way.

The final way you can solve for tension is often people get frustrated when they think that some other function is not performing well. It often if they're dependent on that function as the client, but that's usually where frustration comes into this. It's either someone is not performing well or there's a perception of that. Or someone is a blocker in some way. I think you can get rid of the blocker through the interdependencies that I talked about earlier. I think you can get rid of the perception of low performance being tolerated by having a cadence of meetings where you're going really deep into specific OKRs. I really liked the way we did this at Gainsight.

Let's say that we had four company-wide OKRs. Each Monday in the morning, we would have a 90-minute meeting on a different one of those company OKRs, and the executive sponsor for that particular OKR, together with a subgroup that was essentially the working group of people that had OKRs related to that higher level OKR, would present in that meeting. In advance, they would put together a certain data set and explanation. I think we could improve on what we did at Gainsight, by having a Notion doc, where you explain in detail, here's where we are relative to the OKR; here's what we're forecasting; if we're forecasting underachieving, here's why; here's specifically the three root causes; and here's some data supporting that; here's what I call a “path to green,” which is how you get from where you're forecasting today or where you are today to where you need to be.

That “path to green” is literally a waterfall chart that shows point A and point B, and what's the breakdown of how you get there. And each of the constituent boxes in the waterfall is a different tactic or initiative that you're running to course-correct.

When people send out that Notion doc in advance, a cross-functional group, basically an extended exec team, can read that. And then, during the meeting, it enables a focus on areas of disagreement or enables people to ask questions, to challenge each other in a friendly way. It creates a level of transparency and accountability that I think builds trust among people. And I think it helps ensure people that others are being thoughtful. If enough of these meetings happen and someone's not delivering repeatedly, it becomes pretty clear to everyone. It's not this thing where people have angst about it. It's obvious and therefore can be corrected.

F: The keyword that really stood out to me from what you were describing was the word dependency. I love that because I feel like we don't really hear that a lot when it comes to OKR process. That's not the thing that gets taught the most. I find that interesting, because as operators, we often build process and every process has dependency. When you go from one stage to the next to the process, there's usually something that would make the process go faster, dependencies attached to it, or if there's something going on and you know what that is. But I think in OKRs it's not described that way, which is really fascinating that you've that up. That really kind of put a light bulb in my head: there should definitely be dependencies. It's a great way to mitigate the tension.

I feel like a lot of times we do OKRs in silos. Team leads will go work with their teams in their own little silo, create their OKRs, come back to the executive team, say here's what our OKRs are. So we just did seven different OKRs in silos, and now we're trying to glue them together, but it doesn't make sense. I love the approach of, what are the dependencies in place and how do we make sure you're not going to fight for resources or say your team needs more than this and that. So it's super interesting. I like that a lot.

A: I'm happy you mentioned that situation with functions coming back to the leadership team with their individual goals. That is traditionally how so many companies have been run, and what it means is, there is strictly this functional lens of goals, as you said. Probably each of those functions is managing their goals differently, and they might have different numbers of metrics that they're tracking. Everything might be different about how they're instrumenting their goals. Besides there not being dependencies that are illustrated in that situation, there's also not an understanding of why these goals are relevant to each other and to a broader strategy. If you're an effective founder and you're thinking, "What do I need to do over the next two years to be successful?" it’s probably things like, "I need to make sure that this product launch goes really well." And of course the product team and the engineering team are going to be involved in that. But obviously, the marketing team is going to be super involved in publicizing this lauch. Customer support is probably going to receive tons of tickets afterwards, because maybe there was some bug, or inevitably the feature is imperfect when it was released. And then, customer success and sales have to think about onboarding customers onto this new product, and cross-selling that product into existing customers. I think most true strategic priorities require cross-functional alignment. If you start with what the company needs, as opposed to what each function is thinking they need to do, it ends up resulting in a much truer set of goals, than if you go function up.

F: For sure.

If you enjoyed this post, feel free to share it with another operationally-minded friend, or a CEO who needs one!

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

I’m now including transcripts in these podcast newsletters. Scroll down if you’d rather read than listen!

The delineation between Web2 and Web3 isn’t always clear. Some Web2 companies are serving Web3 use cases. And there are other situations where a Web2 company might incorporate the core Web3 tenet of decentralization into how they build their product or business.

In this podcast episode, I explored these gray areas with Mathias Klenk, Co-Founder and CTO at Passbase. We discussed:

* What does it mean for Passbase to be a “Web 2.5” company?

* What does it mean for them to advocate for identity verification in Web3 — a world historically known for anonymity?

* How do they make money — and are they paid in USD or tokens?

See the lightly edited transcript of the podcast below if you’d rather read than listen. I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles:

As always, I’ll share some leadership roles at companies that I’m excited about:

* Passbase (Matthias’ company!): several roles here

* Workstream:

* Head of People

* Head of Content Marketing (Utah or SF) 

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* LaunchNotes:

* Customer Success Team Lead

* Director of Engineering

* Palette:

* Product Marketing / Head of marketing (US/Europe)

* Guide

* Marketing leader

* Director/VP of Engineering

Transcript:

Allison: Matthias, thank you so much for joining us on the podcast today.

Matthias: Thanks for having me.

A: I'm psyched to talk with you about all things Web3, and especially how B2B relates to Web3, because there are a lot of people who are listening to this that are in the Web2 B2B world, trying to understand how their careers might evolve in the Web3 direction. I think you can be educational in that area. To start, can you tell us how you got into Web3 in the first place?

M: I drank the Koolaid in 2015 or 2016. When I was at Stanford, everything was about blockchain and crypto. I was very excited about the possibility that cryptocurrency had at that time. And let's be real: back then, there was not really a use case. This was before we saw all these use cases that smart contracts enable nowadays. So this was pre-NFTs, and ICOs were at the 2017 peak.

I went down the rabbit hole, as everyone phrases it. Soon after, I started my first job. I was building a crypto wallet with one of my best friends, which was called Coinance. This was project that later involved into Passbase, the company that I'm running now, where we do digital identity verification - very boring, in the Web2 world. We basically came from the Web3 world, went back to the Web2, and I'm shifting us back to Web2.5. The idea is to adapt some of these concepts and mental models from Web3 and also work with lots of Web3 clients. And then later the question is, how can we be a little bit more the Web3 company that we intended to be?

A: I’d love at some point in this conversation to get more into what Web2.5 means, since I think there are actually a number of companies that identify as midway between Web2 and Web3. But to start out and give more context, I'd love to talk a little bit more about what inspired you to build Passbase and especially exactly what problem were you looking to solve when you started it?

M: You basically have to understand the crypto wallet that we built prior to that Coinance. We started as a portfolio tracker. Pretty much what Coinmarket cap is doing…You could connect your different crypto exchanges and accounts, see your portfolio, and check prices. We built a feature where you can connect all these crypto exchanges and do some arbitrage trading between them. And this is when we then really discovered how cumbersome and annoying it is to prove your identity to all these crypto exchanges. Everyone has probably done it at some point in time: when you sign up for bank account or a crypto exchange, and then you need to take the selfie and a picture of your ID.

From a developer standpoint, it was so annoying to do. And all these old vendors were doing it. It was slow and very annoying. We looked at it from the lens of, here is this Twilio or Stripe approach where you just get your API keys and integrate it, and you're done in a few hours — versus when we built it, it took weeks.

So we said, Hey, let's not build this crypto app anymore. We should rather focus on solving identity, not only for Web3 and crypto companies, but actually for financial services and many others, because we really saw that as the world becomes more and more digital in the future, we will have to do this over and over again, not only once or twice a year, but probably five times or maybe even more and in the future.

Proving your identity, that you are real, is touching almost any business transaction, especially when it comes to money laundering, everything that is somewhat regulated or where there is trust and safety component. Those things combined motivated us to try to fix and solve identity verification online and we then pivoted into that. That was a little bit more than two years ago.

A: Super interesting. Diving in a little bit more, do you do identity verification only for individuals or do you also do it for companies?

M: This process for individuals is also referred to as KYC. “Knowing your customer” process in a business context is KYB — “know your business.” We solely focus on the individuals. So we just do this on an end-consumer basis. There are companies that focus their whole company on that know your business aspect. Also the know your business aspect is a little bit more hairy and difficult because as you can imagine, the whole world has different registries and different company structures. Some are more open, accessible, some are less. And it's still sometimes a very manual process, how to check and find out what are the beneficial owners of a company. And then as you can imagine, that can be a company that is owned by a company that's from a company that is sitting somewhere in the Caymans.

Versus for us, the starting point was literally computer vision. I took the Stanford class on taking pictures of an ID document and then using computer vision / OCR / optical character recognition, then comparing those things.

A: Now, is there a B2B Web2 company that you are competing with in this area? And if not, is there a Web2 analogue that you would identify with?

M: Yep. The market is fairly crowded. So nowadays, in the US, for example, there's the old companies and layers that started maybe 10 years ago. Jumio is one of the big US companies that took a more modern approach to that. And in Europe we have Onfido or IDnow from Germany. There are in total already up to 10 companies that I would say we are somewhat competing with. We on the other side, really try to focus on a small niche nowadays. And also in terms of product roadmap, we’re more focused on the Web3 world. So we now thinking about more Web3 features.

There's now this thing called KYT, which is know your transaction, in the Web3 world that is very relevant. Companies like ChainAnalysis or SIS became big with that. So we're thinking about offering partnerships or product offerings with them and just really try to provide value to our Web3 clients as a holistic kind of identity verification company that helps them in staying compliant, following regulation, and verifying their users. Because in the end, this is what all these crypto companies haven't been doing in the past. And just the last two years we really started to do and to realize, oh, we actually need to comply and follow the regulations. Otherwise they technically contribute to money laundering.

A: Now I know at the start of our conversation, you said you're kind of a Web2.5 company. I'd love to dive into that a little bit more. For example, you've made it clear that you're serving Web3 use cases. I'm wondering to what degree is your product itself a Web3 product?

M: Things that I'm basically spending lots of time on right now is thinking about how can we adapt lots of these mental models and ways how Web3 companies work and bring that basically to the boring Web2 world. And this basically paired with the trend that Passbase is betting on is basically that decentralized identity in a particularly user-owned digital identity will be a thing in the years to come. And so projects that I'm spending my time on right now is thinking through how can we enable end users that are running through our verification flow, that we can enable them to claim and store their own digital identity on their end. So things that I'm looking into is in relation to Web3, how can a user, right on chain, prove via their crypto wallet, that they have actually completed a verification.

And the next time when they connect their wallet to any decentralized app, how can this decentralized app somewhat access and see that this user has actually completed a KYC verification to stay compliant? And here public blockchains are super interesting for me. So we have a prototype, for example, with Ethereum. Is it possible if a user completed a verification that we air drop them an NFT to that wallet. That this user has somewhat a passport NFT, whatever we call it, then. That is still bound, so it also can be transferred the next time they connect their wallet. We see this user has somewhat his digital ID NFT and say, Hey, I'm good, you don't have to verify my identity again. So this is the way I try to push the product roadmap vision of the company, from maybe Web2 to Web2.5.

But it's an illusion that we will ever land in a Web3 world, because we are operating in a highly regulated space and blockchains are not known for being good places to store PII in general. You should not store social security numbers or a document number of your passport on a public blockchain. But again, you can store cryptographic proof, which is somewhat encrypted and hashed, then try to tie this back to a very centralized old Web2 world in a database where this data is sitting and then try to tie the knots together between the companies that they access.

A: I want to generalize what you shared for Web2 companies in general. What do you think are the reasons why Web2 companies should embrace certain Web3 principles?

M: What we are currently seeing here in the last few years is basically a movement that has started. This wave is coming. Web2 companies should now realize that privacy and data ownership are real things that are probably here to stay. And if you, as a Web2 company are not embracing it, you will have inherently a disadvantage versus your competitors. The future of social networks will be built around NFTs. They will be built around creators. Creators will have tokens. Creators will be incentivized to get their community behind those, because this is a way you can get fans to support you, and your fans are benefiting from that. Companies are using air drops for a rewarding early users. There's all these mental models and concepts.

At this moment, that’s a very niche thing in the Web3 world, but companies will all soon swap over. And then suddenly at some point in time, we will not refer to them anymore as Web3. Cause it's just the thing. If you are a company you want to reward your users, you'll do it. And the biggest hinderer from this explosive growth is still this UI problem — it's still so cumbersome and difficult to create wallets for your users.

But I think as this becomes more and more normal and everyone has a crypto wallet or crypto address, these things become easier. The same way everyone has an email nowadays and nobody questions that anymore. So I think in really five or ten years, probably everyone has a crypto wallet tied to their bank account or their email address or their phone number.

We see this already nowadays in large social networks. Twitter is basically embracing NFTs as profile pictures. Instagram publicly shared already that they will also work on NFT integrations. And all these things will just become more natural and mobile at some point in time.

A: I want to talk about how concepts that certain go-to-market people in the Web2 world might have to embrace if they were moving into the Web3 world. And then on the other hand, what might be similar to what they're currently experiencing. Using your company as a test case, I'd love to learn more about your GTM in terms of, who are your target customers? What kind of pricing model do you have? What does revenue look like? And, are there certain people that you're hiring or already employing in GTM?

M: One role that hasn't been too common and popular in the Web2 world, except developer tools, is this role of a community manager or a developer relations manager. All these Web3 companies have a Discord. They have people dedicated to keep the community engaged and get them somewhat to support their product because they understand their only chance of succeeding is if users adopt their crypto or their token or whatever their project is for building on top of their platform. And I think that this is somewhat a GTM strategy that hasn't really been there five to 10 years ago.

Stripe has been doing a fantastic job at that and winning the hearts and minds of all the developers. This is the reason why Stripe is doing so well — developers love integrating them and using their product.

We can see this in Passbase that if we make our integration very easy with strong technical documentation and dedicated technical support, with videos, almost everything that a community manager would be doing and helping our developers, we will make more business because more clients will integrate us. And this is in the end, is how we make money.

Nevertheless, we’re pricing in a boring way, on a per-month, per-verification basis. So we don't have a token that somewhat incentivizes it. We’re not doing tokenomics.

A: Can you talk a little bit more about how you charge and make revenue?

M: We basically have different plans for depending on how many verifications you are doing per month. So we have a platform X this fee, which is just for accessing the product per month. And then on a per verification basis, you would pay us almost $2. So we somewhat usage based and are growing with our clients.

A: Do you ever accept payment in terms of a non-US dollar token?

M: Yes, we have done it in the past. We had clients who paid us crypto. But we are actually also the first, or even the only company in that space that accepts it. I think we even launched a press release on that — that we were the only ones at that time. I don't know if our competitors now accept it as well, but yes, we have been paid in Ethereum and in Bitcoin.

A: And I imagine well, the fact that there are more companies that are doing this, like you, is probably giving rise to these treasury management products that we're seeing on the market. Is that right?

M: Yeah. I think it's going to be a big need that market to fill. There needs to be a custodian crypto bank that partners with all companies that helps them store their crypto in the future.

A: Let's say I'm a candidate who is currently working in the Web2 world, but I want to get into the Web3 world. What tips should I keep in mind for how to go about finding my new job?

M: There are lots of great conferences and events nowadays that you can go into. I flew a few weeks ago to one in Denver, which was a fantastic event. I think just last week there was a big conference in Miami. So I’d encourage everyone who's still working in Web2 and is interested in breaking into Web3, just go to these conferences. Get to know those people and somewhat embrace it.

If you do not yet own any crypto, it's probably worth at least looking into that. No financial advice here, of course, but you should definitely at least get yourself into it. How do I borrow it, buy an NFT? How can I buy a Bitcoin and all of these things. And then, try to get to know the industry, how it works.

M: Because I think unfortunately the Web3 world still is very tribal. We have our own lingo, all these things and acronyms — like GM for “good morning” — which doesn't make it very inviting to outsiders. So if you read some of these tweets for the first time, you're like, what the hell is this person writing? So I encourage everyone to just try to understand what those people say. Talk to them and get to know them. And nowadays, so many companies are working on cool Web3 projects. There are plenty of opportunities and roles open.

A: Any roles that you're recruiting for that you'd to broadcast on this podcast?

M: We’re currently recruiting for developers and community managers. Right now I'm basically the evangelist and the community manager. We always are open to good engineering talent, as well as people for our business development and marketing teams.

A: Matthias, this is a super educational conversation. Thank you so much for having it with me, and looking forward to continuing the conversation as you grow your business.

M: No problem. Thank you for having me. It was fun.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

The “modern data stack” has been a gigantic leap forward. It feels cutting-edge. But might there be an even newer frontier?

In this podcast episode, I take another trip down the Web3 rabbit hole with Danny Zuckerman, Co-Founder at 3Box Labs. We discussed:

* What does the Web3 version of the "modern data stack" look like?

* What is the value of decentralized data?

* To whom is it valuable?

This conversation was mind-blowing to me. Feel free to reach out to me with any thoughts. You can also read the lightly edited transcript of the conversation below. Let's dive in!

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about.

* Various roles @ 3Box Labs (the company that Danny leads!)

* Head of Marketing @ Swantide

* Workstream:

* Head of People

* Head of Content Marketing (Utah or SF) 

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* Director of Engineering @ LaunchNotes

* Product Marketing / Head of marketing (US/Europe) @ Palette

* Marketing leader @ Guide

Transcript

Allison: Danny, I'm so excited to have you here on the podcast today. You are squarely at the intersection of the data world and the Web3 world, both of which I’m very interested in. And I'm excited to help folks like me, who are coming from the Web2 world, understand why Web3 might be relevant to them and to the data world. So thanks for joining us today,

Danny: Of course, excited to be here, Allison.

A: To start out, can you tell us about exactly what your company does and how you got started?

D: I'm one of the founders of 3Box Labs. We got started about four years ago and have actually been working together even before that for a couple of years, trying to make decentralized and especially composable data possible for application developers to build products and services with the web.

What that really means is there has been a vision for quite a long time, going back to the dawn of the web, where the data that's generated, that powers most of the web, instead of being isolated and fragmented on siloed servers behind each individual application is instead shared across apps, products, and services, and is hyperlinked together so that you can build on it in really interesting ways. And in ways that give you a much more seamless and powerful experience across the web.

To do that, you need a few new primitives that didn't exist before Web3, a decentralized way to manage this data, and a way to store the data in a decentralized way. We started to build that the last couple of years. Our focus has been entirely on spec’ing, building and shipping Ceramic, which is a decentralized network for composable data that is open source and that eventually the community will fully govern and control.

A: For the lay folks out there, can you explain a little bit about what decentralized data means? And then also I'd love to learn a little bit more about your perspective about what open source means in your context as well, and whether it's different from open source in a Web2 world.

D: Decentralized means so many different things. So it's good to ask that question, and frankly, we should get away from using that as the leading term in our space. For us, what it really means is the opposite of siloed. Siloed is the result of centralized data.

When we talk about decentralized data, it’s less about, “let's get every app's data to be stored on each of our phones and laptops and away from AWS.” That is one form of decentralized data. But it's actually the control plane for data that we really care about decentralizing. So again, all these apps, products, and services that we use online are powered by code and data, to dramatically oversimplify. And the data is what fills them with information, which makes them very rich and useful, and also makes the apps that aggregate lots of users and data very powerful, because they have the data lock-in and network effects.

The idea of decentralized data is, let's remove this really powerful data from the silos of any one application or platform, so that the data that I have access to on a random new mom-and-pop e-commerce store is exactly the same as what I might see on the Shopify store on Amazon or anywhere else. When we say decentralize, what we really mean is changing what is often called the owner, but we really think of as the controller of data from single monolithic platforms, to anyone who participates in building or using the web and really pushing control to the edges, so that data can be brought from app to app and follow us around our experiences.

A: Anything you would add about what open source means in your context?

D: Open source is most commonly talked about for software. Most of the web today runs at least to some degree on open source software. What it enabled was apps everywhere to use the same code, not recreate redundant code that did the same thing. So it saved massive amounts of time and created a composable software stack that the web now runs on.

As open source was for code, blockchains are for finance. It's like open finance. It's a way to store this financial assets in an open, shared, composable way, where you now have what people call money legos.

We talk about open data as the final piece of this Web3 stack: instead of every app having a bunch of backend engineers design their data model, run a bunch of servers, completely the same as every other app, we can build the same data sources, data sets, and data management tools. This is much more powerful, because you get to share the same data across applications.

So this is really an extension of what's started with open source software.

A: I know there's a lot of debate broadly in the industry about what are the benefits of decentralization versus what are the benefits of centralization? Given security concerns and others, sometimes centralization makes a comeback. What do you think is the value proposition for decentralization, specifically for data?

D: I think there are many. The biggest one in my mind, though, is this composability — the ability to natively share data across the boundary of any given application or platform. And that makes every piece of data more valuable. Because now it can be used in more context, and instead of having to recreate it everywhere or have a limited experience with each app, you now have your whole identity, your whole set of data with you to interact with.

We have that in a super limited way on the web today through APIs. That's how centralized services have tried to make their data shareable beyond boundaries, but it requires an explicit decision by the company to give access to it. Often those are metered, and also it requires one-off integrations every single time you want to share that data. So it's a super, super limited form of composability. And it's also always at the risk of that platform turning off that API, which Twitter did with all their developers and Facebook has done with all their developers. Anyone time someone builds up enough power, they just do it.

This is a way to have native composability — a single API for any data that you want to get to.

That's not the entire benefit of decentralization, but it's the one that we think is going to drive the most adoption. We think especially startups will capitalize on this benefit, because now instead of having to build their user bases, data set, and social graph, from zero all the way up by themselves, now they can build on an open social graph, open data set, all the user's existing data. And so they get to very quickly leap ahead to where they would've been otherwise.

A: I think the Facebook example that you shared is a really compelling one because we've seen how much, as you said, Facebook has really amassed a lot of power because they can set limits around who can access their data. I'm wondering in a world where data is decentralized, do you think there will be less of a tendency toward monopoly that there will be a greater distribution of power among players? Will there be more competition? How do you see it?

D: Yeah, 100%. I mean, there will always be vectors towards centralization. So this will not eliminate some of that forever, but yes, Facebook people talk a lot about censorship when it comes to Facebook or Twitter, some of these other big social platforms, because they have so much power and we live there. They do have this censorship power that is so important, but that is tiny compared to the much bigger issue, which is the lack of innovation that happens because nobody can compete with Facebook. That’s because Facebook has such an entrenched advantage with the social graph and the data that they have. And so when users can opt to take their data with them to use multiple products at the same time, that lock-in isn't there. And so the bar for competition is much, much lower and the switching costs are much, much lower.

In traditional web, we often hear people talk about the need for a 10x better product. It has to be 10x better before people are willing to go through the pain of switching away from one to the other, because it is a real pain to switch. But when you can take all your data with you, it's not zero pain to switch, but it's not very much. I regularly switch between, for example, Zapperfi and Zerion, which are DeFi apps that access the same underlying data because they do slightly different things. And when you can switch that fast, you don't need a 10x better product. You need just a slightly better product and then you can start using it. And so one product might not be 10x better, but very, very quickly with that compounding innovation, you're 100x better than you were before. And so that permissionless innovation is what we think is really the most exciting and valuable part of composable data.

A: Do you think that Web3 data companies will replace Web2 data companies in the future? It's a provocative question in part because there's so much attention being paid to the Web2 data space right now. They command enormous valuation multiples. There's so much innovation happening, probably thousands of companies that are attempting to produce a product in this space. If actually those are at some point going to be disrupted by Web3 data companies, that's very interesting. What do you think that disruption path might look like, if it exists at all?

D: Think a lot of them are here to stay for quite a while. This is an imperfect analogy, but when we went from Web1 to Web2, on prem databases didn't completely disappear. There's still a role for them in certain circumstances. Similarly as we go from Web2 to Web3, centralized databases and centralized models won't completely disappear. There's still a role for them in the near-term for anything that's super, super low latency requirements, because decentralization does come at some cost, including latency. But web apps were higher latency than native apps, but they had all these other benefits. So people adopted them. But for certain very, very sensitive data, you should not put it on an open network, even encrypted.

There will always be a need for some form of even distributed, but centralized database storage, running very rapid analytics or AI models. Maybe you want to have a centralized data warehouse for those things. So there's things in that data stack that I think even as the web shifts from Web2 to Web3, those companies can adapt and play a very big role.

But I do think that in the order of three, five years, I hope, no new app is going to be built with a Web2 siloed database model from the beginning. You're not having to run a backend yourself. You're building on this composable ecosystem of data, and data models will just be so much bigger that no one would think to try to compete with all of that on their own. And so it won't happen all at once, but I do think it will start to happen more and more rapidly pretty soon.

A: That's so interesting. I'm wondering how the split of Web2 and Web3 will work. For example, do you imagine a data company having a centralized solution as one of the products that they sell, or could you imagine customers buying Web2 solutions for some use cases and also the same company having a Web3 solution for another use case?

D: That's an interesting question. I definitely think there will be a mixture in this stack, that companies will use a combination of centralized databases and Web3 distributed databases, just like companies today build their applications on a whole bunch of different databases. You might use Postgres for one thing and MongoDB for another, depending on the use case. So I think similarly, especially in the next few years, you'll see applications built with some stuff stored a centralized server, and analytics services and like all these extremely sophisticated products that are built up on the stack. But then for very core things where they need to tap into composability, they'll use Web3 data and then more and more, the Web3 stack will get more mature, more and more products will either be built or migrated over to serve them. And more things will migrate over. But I think there will be a mixture for quite a while, for sure.

A: For the companies that do decide to procure Web3 data solutions, what are the benefits to them in a concrete way and what might be the benefits to the end users of those web3 customers?

D: I'll start with the benefits to end users. People often talk about they'll have control of their data. They'll be able to have the same experience from app to app. They'll have lower switching costs. All of these are true and I think dramatically undervalued but it is very hard to get end users to take action on behalf of any of these fairly abstract benefits, including privacy, which is one reason that we've always focused on serving developers, not end users, as the route to get all of this adopted. But then end users will start to go to applications and have all of their data follow them there and have a way more customized experience. They won't feel like each time they go to a new app, they bend themselves to that app and its forms, its onboarding, its social graph. Instead, the internet bends to them and becomes their metaverse, to use the term that is sticking now and similar to how, very quickly, once we all had iPhones and everything was cloud, it became extremely painful to not have access to your Google docs or not have access to your messages or whatever, even when you were traveling and away from home or like once we felt it, we could never go back. It's going to be like that. But it's just in a different set of dimensions for developers. It's speed and cost of power are the things that you get when you build on the Web3 data stack.

Building on a shared data infrastructure, you don't have to stand up your own backend. You don't have to run the backend and maintain it. That's all happening on shared infrastructure. So as a front end developer, or pretty soon, even as a visual developer (whoever makes the call there) that call their kind of no-code coders, you'll be able to build a full application very, very quickly, because you don't need to build a back-end. You just pick and choose the data models for the features you want. You want your social graph, your blog buzz, you just use existing ones and that's your data portal. And then you throw it into the front end and now you have a full stack app. So you can build something much faster, get adopted much faster because users bring their own data to you. And so now you have an entire social graph right off the bat.

As an end user, I could choose to use Notion while some of my team was still using Evernote. We all go to what we want and everybody gets to still collaborate on the same data.

Because of composability, the experience that you as a startup are delivering to your users doesn't necessarily end when they leave your application, because they might write a blog post on your app because you have the best writing interface. Then they go to another app that's using the same underlying set of content, the same blog posts, but a whole bunch of comments are being made there — because it's designed more for social. Well when people come back to your app, those comments come with them too. And so the total experience that you're delivering is much wider than it used to be.

A: To make things more concrete for the audience: who are your target customers?

D: Right now, we are purely working in the core Web3 community. Everybody building on top of Ceramic today are part of either a blockchain ecosystem, building blockchain applications or distributed data applications, basically people who are already believers in some of the value propositions of this more distributed way of building applications. The reason for that is there are tradeoffs in this tech, including speed and reliability in certain ways. It’s folks that have been building in the Ethereum ecosystem, because that's where we have spent the last five years. They’re building a lot of collaboration tools — everything from note-taking, to future of work stuff, to communication.

DAOs, which don't necessarily have a traditional org structure, and many other projects that want to collaborate more fluidly, benefit from this composable data, because people can collaborate much more naturally. There are ton of reputation-related projects where reputational data is aggregating around the user. Let’s say you've done projects, you've completed an import of your financial history to get a decentralized credit score. All these things are being built on Ceramic today.

A: Danny, I'd love to get an understanding of your view of what the modern data stack would look like in the Web3 context. And especially if you've thought about what the analogues of Web2 companies would be in the Web3 context. That would be an interesting translation.

D: I do think that the stack is still in some ways sorting itself out, and it won't be similar to the Web2 data stack. Especially, it won't be a super clean stack. There's going to be so many different protocols that play in very thin layers and plug in in different ways. We don't know exactly what that looks like yet, but at the high level, the analogies for the raw storage layer — data centers in Virginia with AWS — are things like Filecoin and Arweave. And those provide at this point very well proven distributed file storage.

Then on top of that, you have the database layer. I called Ceramic a distributed database earlier, but that's only half true. Ceramic is like the “write” side of a database — writing transactions to a dynamic data protocol that then can be stored on Filecoin or Arweave. The flip side to the “write” side is “read” — indexing data and making it queryable, which is really powerful in Web3 because this data can be indexing all these different data protocols, blockchains, and Arweave and Filecoin and Ceramic, and making it all queryable in a single API, and making that all accessible to an application in one very easy interface. So that's kind of the “read” side.

And then on top of that, to dramatically oversimplify, are lots of different SDKs and dev tools that wrap these up and add different features and different components to them to make it really easy for developers to build on top. We are huge believers in the idea that devs really want to choose the right stack and right permutations for themselves.

There are a bunch of messaging protocols to share messaging between different applications in a centralized way — including XMTP and EPNS and others, lots of analytics protocols that can use this data.

There are identity companies like Spruce and Privy that are adding more sophisticated privacy and permissioning models to all of this.

The last one is the wallet layer — authentication — to actually sign these messages and manage this data. Magic, Web3Auth, MetaMask, and Phantom and others are the most user-facing of the stack.

A: In closing, Danny, I'd love to know, are you recruiting for any interesting roles right now that perhaps members of the audience would like to learn about?

D: We're hiring a product lead, someone that's taken some data products to market before and tons of interesting things around building this data ecosystem, as well as the data products that this person would oversee. Protocol engineers, whether that's from a cryptography background or distributed systems background, but helping build out the core protocol. A community lead to help architect and shape the developer community in Ceramic, which has been growing more rapidly than we can keep up with. A bunch of others too. They're all on careers.3boxlabs.com.

A: Great, Danny, thank you so much for joining us today. This has been a really educational conversation. I learned a lot about how the data space, which I'm really interested in, might evolve in the future. And I wish you the best of luck in helping to champion that innovation.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com

Finally, podcasts transcripts are here! The one below is lightly edited for readability. I’m working on finding a more efficient way to condense transcripts into key points, in line with past written fireside chats that I’ve published, but I think this will still help folks who prefer to read vs. listen. Enjoy!

If you're trying to drive Talent Efficiency at your company, you're probably wondering, how can I help my organization make the best use of every hour on the job? One way to do this is to help your more experienced team members get the newer ones up to speed. But your experienced folks are usually especially tight on time, in part because everyone is asking them for help. How can we help our more knowledgeable team members scale?

I spoke with Jennifer Smith, founder & CEO of Scribe, about this very question. We discussed:

* How do you mitigate the risk to your company know-how from your most knowledgeable team members quitting

* How to quickly onboard new team members

* How to leverage your institutional memory to train customers

I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!

You can also learn more about Jennifer’s recommendations for employee onboarding here. And, as mentioned, you can check out the transcript of our conversation, below the Leadership Roles section.

If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:

Leadership Roles

As always, I’ll share a few leadership roles at companies I’m excited about.

* Head of Marketing @ Swantide

* Workstream:

* Head of People

* Head of Content Marketing (Utah or SF) 

* VendorPM:

* VP of Product

* Head of Marketing

* Head of Finance

* Director of Engineering @ LaunchNotes

* Product Marketing / Head of marketing (US/Europe) @ Palette

* Marketing leader @ Guide

Transcript

Allison: Jennifer, I am so excited to have you on the podcast today. You are an incredible thought leader when it comes to how teams gather knowledge and how they share knowledge with customers — something that people are thinking about a lot nowadays as they're trying to hire quickly and retain folks. So, I'm really excited to have this conversation with you.

Jennifer: I'm so excited to sit down and chat.

A: To start off, I know you've given a lot of thought to how the know-how within a company is built and maintained. So, given how hard it is to retain people nowadays, I have to think a lot of founders are wondering, how do you mitigate the risk to your company know-how from your most knowledgeable team members quitting?

J: With the great resignation right now, you face a double whammy, which is number one, you've got people leaving, and it can be some of your your best people, your most tenured people who are walking out the door. And until you've hopefully got some new people coming in, where you got to figure out, oh, gosh, how do I onboard them really quickly, and transfer all this knowledge that’s left into their heads. And even before the great resignation, I talked to a lot of execs about this, and founders about this, who would say, look, my people are my most important asset. And really, it's the know-how that's in their head. That's my most important asset. All the special things they know how to do both generally, and in the context of my company and how it runs. And it walks out the door every day at 5pm. And I gotta hope that it comes back. And it's really hard for me to try to capture this knowledge, because you really only have two options, right? You either tell that person, Hey, before you leave, take time to write down what you knew how to do, that's a popular ask. Or, hey, I'll hire someone to come shadow you, or I'll ask a teammate to come sit next to you look over your shoulder and write down what you know how to do. By the way, I was at McKinsey for seven years, and I did way more of that work than I ever wanted.

At Scribe, we think a lot about, what if you could just pop open the heads of your most knowledgeable people and automatically pull out what they know how to do? What if you could build this collective know-how and capture all of this info, because that's really what your company is running on every single day. It's all of this special knowledge that people have.

A: The most knowledgeable people on your team are often really busy, because everyone is always asking them for help. This was often true at Gainsight on our customer success team. There were people who had been at the company for a while and had met with tons of customers. And they were often the go-to people for newer team members, but I often found it overwhelmed them. And so if they're spending their time helping other people, team members, customers, then they may not feel that they have the time to impart their knowledge in a more permanent, scalable way, as opposed to having these one-off conversations. So how do you cultivate this focus on enabling others more scalably?

J: This is something we hear a lot too, because we will talk to those people. And you can find that pretty quickly, within a company, everybody knows who they are. They'll say, oh, we really need to talk to Lauren. And then we talked to Lauren, and Lauren is incredibly knowledgeable, has usually been there for a few years, and is usually a pretty helpful person. She’ll say, I'm spending a lot of my time explaining to people how to do things. And so we think a lot about how can you pull that knowledge out of Lauren's head, but in a way that doesn't tax Lauren's time, because that's also a double whammy. If that person's your most productive person, their time's worth even more to you. And so we've said there really needs to be two key components and thinking about for us Scribe, which is what we use to pull that info out of someone's head is what it needs to be really high ROI for them. So it needs to be incredibly low friction, take very little of their time to do and they need to understand that there's a lot of value coming out of the other side for them doing it. And then to think about what are the positive feedback loops to that person as well that say, hey, you did this and it helps these people and here are the results coming out of it. And the key is to do that in a way that doesn't take them out of their flow of their day to day work. So, we think about how can we be capturing this know-how from Lauren, while Lauren's just doing what she normally was going to do when she showed up to work that day. And out of that, can you create scalable media that can now be shared not just with that one person that Lauren happens to talk to? Because they ping her to ask a question, but now with anyone who might have that question now or in the future.

A: A common question I hear from founders is, how do I quickly onboard new team members? So what are the best practices you're observing?

J: There's three components to it. There's kind of like the big piece of just helping new people understand the overall vision and mission of the company. What are your goals overall? What are your goals for the next quarter?

And then how does their work particularly tie into that? How are you viewing success within their role? What are the things that you're going to track and measure? So sort of the why behind, why are they here? And what are they doing?

And then I think the next piece, and this might be arguably the most important of the three, is the who. So, having someone feel like they're an integral part of the team and try to create that as quickly as possible. I think there's a lot of research around creating psychological safety and the importance of that within teams. And so how do you help people when they're first getting started to understand who are all the people that they're going to be working with, and help them build relationships with them?

There's been a lot written about this, we've got a bunch on our blog about this. But some common things that people will talk about are, in your first few days, make sure that you're bookending everyone's day — especially if they're remote — with a check-in. Hey, here's who you're gonna meet today, here are the kinds of things you might want to ask them, here's why they're important. And at the end of the day, how did it go? What did you learn? What are open questions that you have, and then making sure throughout those days that they're getting opportunities to talk to the right set of people in in both a formal and casual way. So, they're building those kinds of personal relationships.

And then the last piece is more tactical, making sure people have actually the resources, they need to feel like they can be successful at their jobs. This is an area where you see, I think it's really hard to do, and you see a lot of companies fall down. And so a recent Gallup poll that said that 29% of people in the US feel like they have the resources they need to succeed at their job after being onboarded. After companies have put all this effort into it. I think it's an area where we can do a lot more within Scribe, we think about that a lot of like, what does the know-how that people need when they show up to their jobs?

So okay, you've told me what I need to be doing. You've told me what the company is trying to do overall, and how that matches, you've told me who I'm going to be working with, you've maybe done some basic onboarding and training around the skill set required. I'm now butt-in-seat and I've got to open up my Salesforce and figure out where my opportunities lie. Or I've got to generate my marketing report. How do I do these really tactical things? And when you're sitting together in person, you'll often see people just pop their head over the proverbial cubicle or tap someone on the shoulder and say, hey, can you just show me how to do this? When we're remote, that becomes a lot harder and becomes again, a tax on your people who are now getting Slacks and Zooms and emails with people asking them how to do something, or I would argue even worse — people not asking at all and just sitting alone trying to onboard themselves and figuring out how to do something.

I think we often think about onboarding as being the first week or the first couple of weeks in a job. But I think we should really think of it as much longer, six to 12 months often, because there's a lot of parts of a job, especially in more established companies, where you only do it once a quarter or once a year. So, you're continually bumping up against what are these new things that I haven't done before? And how are you continuing to transfer that informal learning that happens peer to peer, but doing it in a way that's more accessible and more scalable for the new people coming in?

A: I have to imagine that in a remote environment where you're not seeing folks face-to-face as a new hire, it might be nerve-wracking to raise your hand and ask questions if you don't know something. What have you noticed in terms of the best practices for enabling team members in a remote environment, particularly keeping in mind that some subset of them might be particularly anxious? And then for candidates, what are you noticing are the best practices for them to make sure that they get up to speed quickly?

J: When you're in person, I think sometimes it can even be daunting to pop your head over and ask somebody. I remember starting some new jobs and not wanting to bother the person sitting next to me all the time, every time I had a question, and there were a lot of them. I think that barrier goes up even more when now you have to send a message to interrupt someone's day. And so I think there's something teams can do on that side.

Again, I think creating a lot of these more like informal times where people can connect so they can even understand who are the people I could be asking questions of, because there's really three parts to it.

One, you have to understand you don't know something, which sounds trivial, but not always obvious. A lot of times people don't even realize they don't know.

Two, do I know where to go to get that info, whether it's a person or some kind of knowledge management platform that my company is using?

And then three, there actually has to be an answer within that.

McKinsey did a study recently that said, the average knowledge worker spends 20% of their time just trying to find info on how to do their job. This is not people who are just onboarded — this is even people who have been doing their job for a while. Like one out of every five days. And so how do you make it so that it's easier for people to be able to get that info and not be pinging others?

We think a lot about that concept of, what if instead of going and asking someone how to do something, you had it written down somewhere? What if it were just sort of seamlessly documented? And you could have this kind of like collective intelligence of your organization?

I think it's incumbent upon, to answer your question directly, the person who's coming in, to feel empowered to ask those questions. And I think this is something we try to do whenever new people join Scribe is say, if you have a question on something like you're not going to be the first one or the last one. Find that info. And because we're Scribe, we say create a Scribe. If you don't find the Scribe for what you're looking for, find the answer, and then create the Scribe so that the next person doesn't have to go through that same exercise. And we're trying to create something that's more scalable.

A: Maybe that's a good segue into your product. I think folks would probably love at this point, to understand a little bit more about what does Scribe do?

J: I tend to think of it as like tipping someone's head open and automatically capturing what they know how to do. Scribe's a way to just really easily share know-how, how-to knowledge. So procedural information.

Very tactically, the way that it works is it's a Chrome extension or a desktop application, you click the record button, and then you just do a normal process. You do the thing that you would have been doing at that time during your day anyways. And when you're done, you click stop record, and Scribe will auto-generate a step-by-step written guide with screenshots explaining what that process is, and how to do it. And you have a whole bunch of options for how you edit it. All the info someone would need to understand about how to do this process is automatically generated just from you doing that work.

You can imagine that's used in a variety of different contexts. Really anywhere that someone has to explain to someone how-to. So, hence a lot of your questions around onboarding any of the how-to within a company, how do I generate this report? How do I use this software? How do I find which days we have off? All that kind of stuff that you have every day, you accumulate Scribes of more and more, as everyone goes to then generate one of those reports, they just click that record button, and boom, now you have a Scribe on how to do it.

So, next time someone has a question, they're hopefully not Slacking you and asking you — they're going and finding it in your Scribe.

A: What were people doing in terms of creating scaled ways to share know-how before they had Scribe?

J: You see this today. There's no standard. It's very interesting to see what happens. It's any combination of folks hopping on a Zoom, often and having a one-on-one conversation, to folks having a one-on-one conversation over Slack or maybe in a private channel, to people asking questions over email, to my favorite — I'll see these really lengthy Google Docs or similar word processing document where people will literally copy-paste screenshots and write in text, and that takes hours or days of their time. And the difficulty with all of those is you can tell is, they're quite manual, they live in different places, and they become much less scalable.

We thought about what's the standard? Could you create a standard by which people share how-to? Because right now, if you had a question for me — hey, Jennifer, could you show me how to create a custom email domain — you have no idea what you're gonna get back. I could just pick up the phone and call you I can send you an email. There's so many different ways. And so we talked about Scribe as like, what if you just create that easy, standard way, so people didn't even have to think about it and didn't have to do the work?

A: What are the primary use cases that you're seeing for Scribe?

J: We see it anywhere someone has to explain to someone how to do something. We've actually tried to size up how many how-to moments are there in a given day around the world with 300 million knowledge workers. And if you assume the average one has like five to seven how-to moments in any given day, some are going to have a lot more than that. You're talking about billions of questions that are getting asked all the time around, how do I do something.

We see that show up most commonly in areas like internal operations teams. So I'm scaling my team. I'm onboarding a lot of new folks. Maybe I'm hiring subcontractors. Maybe I'm changing a process or I just adopted a new tool. And I needed to show everyone, Hey, how do you use this new tool in our process? How do we do quote-to-cash in this company? To external facing use cases to your customers or your communities. So sales and customer success, both instances where especially if you're a technology company, you have to show your customers or prospective customers, here's how you use our software. Here's how you troubleshoot some of the questions that you're asking. Here's how I can send you a personalized response to something that you wanted to learn how to do in your custom software. To more community-facing stuff. You'll find help centers that are powered on Scribe right now, where you're answering questions for community around how to do something. But really any of these like enabling moments where you have to show someone how to do a process and you want them to do it in a particular way so that they'll be successful.

A: I have to imagine that you're saving people a lot of time given the kind of manual processes that they were using earlier to try to replicate Scribe in a way or substitute for not having Scribe. Have you quantified how much time you're saving folks?

J: It's an interesting question. Our users have quantified it. So we get messages from folks who will say, I used to spend about five or six hours creating this documentation. I'd create these whole manuals, and they’ll show us what they look like. And they'll say, with Scribe it took me five to 10 minutes. So, we're looking at orders of magnitude of time savings.

What's really energizing and exciting for us as process nerds is when we meet fellow process nerds who will drop us a note and say, oh, gosh, I'd been doing this before and I believed it was valuable enough that I was willing to spend a day a week of my life. I'm creating this every single week. And now I do it in less than an hour with you guys. Now I'm asking myself, what am I going to do with all this extra time that I just found?

As we think about future directions for our product, and one of the things we're building out in response to requests from folks is, can you help me understand just how much time I saved because it's really exciting to me when I start to see adding up what that was worth? And then of course, there's the top line benefits as well. I think it's really easy for us to focus on what is the time that people save when creating documentation. But really, the question is, what do I gain from sharing know-how better within a company, and what is it that you can unlock there?

The soapbox I like to get on is, you have all of this really valuable know-how and it exists within your team. And you're tapping into a tiny fraction of it right now. What if you could tap into the best of it and make it available to everyone? What could you do then with it?

A: I think what's so fascinating is, for so many functions across the classic tech organization, it used to be that they have to get access to tools that were supposed to improve their productivity through an ops team that they were working with, or through their manager. There was typically a top-down sales process. I know that you've pursued a more product-led growth strategy. So you're able to get directly to, for example, the customer-facing people who are looking to cut out manual work. Do you have any suggestions for those folks who decide to use Scribe, in terms of how to get the most value out of it?

J: That's a really important point, which is, I think software before, you used to think a lot about who's the buyer, and you design the features and the bells and whistles that the buyer is going to care a lot about. And we said, what are the things that make our end users successful and help make them shine? Because they're the ones who have figured out how to do valuable stuff? How do we make it easy for them to just share and get recognized for the valuable stuff they already know how to do?

One of the key things we designed for was how can we make this so that people use Scribe not because their boss is telling them to, but just because it makes their day a little easier and a little better and a little brighter. And so as we were iterating on the product, we were always looking at what is the end user? Regardless of where they sit within a company or who they are, whether they can swipe a credit card or not, it doesn't matter. It was really about how do you empower those people, because when you start to get a collection of people who are now using scribe or any tool, really that helps capture what they know how to do, because it's valuable to them. It accrues more value to the organization as well now. Because now as a company, oh, gosh, I have all of this know-how that now exists at the fingertips of everyone in my company. That's worth a lot to me. But I did that without having to force people to use this as a new mandate from above. It was because they individually saw value from it. So it creates these really powerful effects, where the overall company wins more, because now they have more and more of their processes that are being captured and scaled in the right way.

The thing that we tell people to get the most use out of it is anytime someone asks you how to do something, just send them a Scribe. Save yourself the Zoom, or the Slack or the email or whatever it was, you're gonna do. Just send them a Scribe. And then next time someone else asks you that question, send them that same Scribe, so you don't have to create it again. Or even better, just show them where they can go find it themselves. And if you have a question, and you don't find a Scribe for it, just create one. Because then next time someone has it, they can just find it there. It's all about finding what are these leverage moments in a way that just makes it so much easier for you in your day.

A: There are probably a lot of customer facing folks who are listening to this podcast — sales folks, customer success managers. Have you noticed certain points along the customer journey when sales and customer success folks tend to use Scribe the most?

J: It starts at the beginning of a sales conversation. So we'll say with Sales Ops, people who want to think about how to empower their salespeople, right as they're joining to onboard them or to roll out a new tool or whatever. And then with sales leaders or sales representatives, especially in technology companies. As they're having conversations with prospects, they'll say to us, I love sending them a Scribe to show some functionality that I think you might find really helpful. Or if they're going through and doing some kind of pilot or demo and saying, I thought this would be interesting to you. Having that personalized touch came from me to you where I'm quickly showing you how to do something. Salespeople say to us, that's incredibly powerful to me because it means that I'm helping that customer realize value or understand the value from our product so much faster, in a way that to them feels really high touch and concierge. But for me, it took me 34 seconds. And so there's some value in that.

Then obviously as prospects become customers and start using the product, from a success perspective, making sure that they're understanding the right way to be using it. This depends on your product and how complicated it is. But you can imagine even different tiers based on where your prospects or your customers are in their usage, from here's the basics of how to get started, to now that you've been going for a while, here's some special next-level unlocks for our power users.

What's been interesting to me is I imagined that we would see customer success and customer support folks using one-to-many. So we've created this help center library. We send the same things over and over again. What's been interesting for us to see is that customer success teams will continue to send one-to-one Scribes. One that they create just for that particular customer. Because the software is customized for them. So, maybe their portal looks a little different. So the generic help center stuff doesn't work. Or just for the personal touch, or it takes me a minute to create this, but it looks completely personal and configured. So it's worth it to us to spend that extra minute creating a new Scribe, just so that customer feels, Oh, my goodness, they took all this time to put this together just for me, it has my logo on it and looks like my environment. So it's been really interesting for us to see all the moments and ways in which people use it. But the fundamental core is, how do you help your customers be successful in understanding and realizing the value as fast as possible from your product? And so much of that is know-how.

A: How do you plan to evolve your product in the future?

J: Our vision and our mission is to grow the world sharing of how-to. We think a lot about how to continue to reduce the friction in creating that first Scribe capturing and sharing what you know how to do. We look at things like how long does it take people on average to create their first graph? We've gotten that down to 54 seconds. And we're how do we get that even shorter, taking it down to nearly zero? I don't need to think about it. It's almost just flowing out of my head. I'm not taking any extra time out of my day. Then, how do we make it easier for people to be able to discover and search and view and access Scribe content in the moment at the right place that they need it? So as you're going to do that piece of work, what if the right Scribe could come to you at that time? So you wouldn't even recognize almost that you had a question and think to go call someone else. Boom, it's automatically there. And then also that recognition piece as well, helping people understand you've done the hard part of knowing how to do something that's valuable. What kind of value have you created for your customers or your teammates or whomever and sharing that with them in a scalable way? I like continuing to see that value tick up over time, even without you doing anything additional because you create the documentation once and it can be shared many times.

A: Jennifer, thank you so much for joining us today. I learned so much, even beyond our conversations in the past. And I'm really excited for a lot of folks to improve the way that they share their knowledge and work with their customers through Scribe.

J: Thank you so much, Allison. I appreciate you letting me nerd out a little on processes with you.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit allisonpickens.substack.com