Building Adaptable Products for Long-term Growth w/Twilio SVP Product & Engineering + VP Engineering

from the perspective of projects and products that are net new builds and the products experiencing hypergrowth. So we'll talk a little bit about the challenges that arise, approaches for the short to midterm, and kind of when to consider long-term options. Next slide, please. As a reference point, I'll touch a bit on the product I'm currently leading, but the intention here is that these are generalities that apply universally when we're talking about growth. The specifics aren't important, but the primary solution I work on currently is a SaaS solution for a programmable contact center solution. Flex had its 1.0 release in 2018. So the biggest risk when— I think we're on the wrong slide. Would you mind going back a slide? There we go. Perfect. So the biggest risk for a 1.0 is on a continuum between going to market too soon with an incomplete product versus solving for all the things, over-solving on the scope or solution hardening before going to market. So, but regardless, for a 1.0, you don't wanna overbuild, right? You're really there to validate market fit and get customer feedback. And you're gonna solve for some certain amount of scale. Now, in a hypergrowth situation, your customer adoption is likely moving faster than you can keep up with extending the solution, right? This is great. It creates a great challenge for you, but you've got the push and pull of new features versus scale and extending your product versus stabilizing your product. So as you consider these early trade-offs, the temptation will be to add features. And at this stage, remember you're at a 1.0, you're at a GA. This isn't a POC, this isn't a beta. And the most important thing you can provide is stability. Don't overcommit yourself, telling yourself you're going to catch up. Protecting that operating environment for your set of services is the most important thing you can do for your product's brand. Okay, so you're moving along. There's a point in the first 2 years after GA, you can imagine we're there with Flex, where you're going to have a significant hiccup. It may be a sudden change in demand, or adoption of a new use case, or a technical hurdle that you hit. But if you've got a successful product, you will hit something like this. For us, we had a shift in the market, and you can see that highlighted on the slide. For us, it was COVID. We saw accelerated adoption, but beyond what we were used to, we saw new use cases showing up. But the question now is, how do you respond in a productive way to continue your drive for revenue? Remember that on a SaaS platform, not all revenue is created equal. The size and the shape of your customers matter. At this point, it becomes important to be crystal clear on what your customer is with the current offering and be ruthless about serving that customer. Don't ruin your credible— don't ruin your credibility by chasing a flagship or a particular logo that you can't support at this time. So the answer may not be to chase the big whale or follow the new use case. It may be— it You can do that in— excuse me, you can chase that whale, you can chase that use case in the background, but focus on those customers you can serve now. And the effect of doing this at this point is really about looking at the full cost of obtaining that revenue. All things being equal, a particular customer or customer type may drive up your maintenance costs in the background in a way that drives down net revenue. It's tempting to focus only on that top line revenue at that time. Next slide, please. OK, perhaps your 1.0 is perfect. You've hit a home run on all aspects of market fit, use case coverage, and architecture. I offer you a hearty congratulations, and I'd like to meet you after this talk. But assuming you're mortal like the rest of us, let's look at getting over that hump of continuing to mature that product for continued revenue growth. Right? You're 2 years post-GA or somewhere in that neighborhood. Have you hit the product viability and really confirmed that you have a product that's viable for the long term? But have you? If product viability hasn't confirmed and you're still not seeing the CAGR you need to be successful in the long term, consider an exit to create capacity for revenue elsewhere or consider an invention on a new product. The risk at this point is becoming emotionally invested in an early product. or focusing on recovering those sunk costs in that early product. And now's the time to prioritize. Okay, you're a little more mature. How do you best drive revenue growth? Take time to formally prioritize. Avoid that tendency to just follow the sales leads. And depending on your customer base and your market projections, this is going to be different. This isn't a textbook answer that each of us have against features or scale or stability. And as an example, contact centers are generally mission critical. So I'm going to be in line to look at stability over features, for example, but yours might be a little different. And now's the time to start looking at driving down your cost of goods sold, your COGS. And I find this is often overlooked. Revisit those specific implementation points where you made fast choices along the way to accelerate to market. I've listed one here in terms of over-provisioning versus auto-scaling, or perhaps you've choo— chosen a managed solution that could be addressed as part of your internal infrastructure. And if you weren't careful, KTLO, your maintenance efforts, can start to eat you alive and really erode that net revenue in the background, regardless of what your top-line revenue is looking at. And I'm not saying these are inexpensive to fix. These may be big commitments, but keep in mind that that payback will be perpetual. It's not going to be the one-time payback. It continues to drive down that COGS in the background. So at this stage of the product, we have enough information to consider whether that original architecture is going to carry us. Have we built something that's going to carry us for that 5 to 10-year horizon? Next slide, please. So at this point, we have enough data to understand where the product's going. Don't just look at the customers that got you to where you were in the first couple of years, but where are the customers pointing you to in the future? Your use cases may have changed along the way. While you've been maturing the solution. And you— your 1.0 may not be able to carry you forward regardless of how well it was originally architected. So as you evolve and grow the product, whether it requires a major overhaul or just continued scaling efforts, there are going to be pitfalls and temptations that you want to focus on to avoid a major erosion of your revenue. So one that I fear the most from the engineering perspective is solving for specific customers. This is changing or adapting your actual roadmap to capture a single customer. In almost all cases, you will back yourself into a corner. Best case, you burn a ton of cycles accelerating a roadmap item, deferring other work, and taking on tech debt. And in the worst case, you now have a customer that you barely got over the line that now has a long list of requirements that you need to hit for them that may not match your long-term roadmap and can essentially hold your product hostage by consuming all or most of your dev resources. Resources. The other one I worry about is horizontally scaling by stamping out copies of your instance. This may sound good in the short term, but you're going to take on tech debt. You're going to drive your maintenance costs through the roof, and you're probably going to lower your copy quality because now you've got copies of your code in multiple places. And it might sound good when you have 2 instances. What happens when you have 10 instances, 15, 20? You can kind of see where, where the math goes. And tech teams also have a responsibility in this entire revenue capture process. How are we partnering with product to drive those COGS down? How are we looking at it over time? So we need to be providing input on cost to develop, help the business make trade-off decisions using a Pareto principle. What are the— how do we get 80% of that solution? And then we talk about the cost of that last 20%. And then push back on solving items in the short term. Engineering holds responsibility to partner and educate when there's a short-term solution that sounds good today, but may cost in the long term 10x to fix. And finally, remember, with any major overhaul, your product's starting back at a 1.0 in terms of technical maturity. Hardening that solution will be key, and this may cause a hit to your revenue as you onboard more slowly than you had previously done, and that you expect for the future. So with that, I'll pass it to Vijay to extend this topic with his learnings.

All right, thank you, Jessica. Hard act to follow, but let's see what we can do. Okay, so I am in charge of the accounts platform at Twilio, which encompasses billing, and we— today we will focus on billing. And it's a good counterfactual to all the lessons Jessica learned, because over time in billing, we actually didn't follow almost any of our recommendations. So it's a great, great counterexample. So one of the things, here's the background, right? So the billing platform for Twilio processes all revenue for Twilio. Every single SMS message runs through the, the revenue for that runs through the billing platform. We do over 4,000 financial microtransactions per second for Context, this is about twice the transaction rate than VisaNet, which is the largest payment processing transaction engine in the world. And volume is growing 70% year over year because thankfully Twilio has been successful. As, as Jessica mentioned, we had a huge ramp up because of external, extraneous circumstances like COVID. So what we didn't do, and which is what Jessica talked about, is that we took a lot of shortcuts to keep up with new product introduction. Twilio is a super innovative company. It keeps making new products, new ways to sell stuff, new customers get onboarded, new suppliers get onboarded. So the billing platform took a bunch of shortcuts over time to keep up with the new products and the new customers. We didn't follow Jessica's advice. We did optimize the platform for specifics. All of those started to cause the systems to come close to congestion collapse. Right now. So we had to do some very painful negative revenue. So this is the counterfactual to Jessica, how to increase revenue. This is how to hold back revenue, which is super painful because I have to go to the board every quarter and get, get my licks in. To make this work basically at the rate of growth we were seeing, we basically had to swap the engines on the plane while it was flying. Which is harder to do than it looks on the slide. So the first thing we did was we identified the core systems that had to be refactored based on the queue length. And then this is the super painful part. We jettisoned all go-to-market requests for new customers, new billing modalities, new geographies, new currencies, to focus on the refactor. And this is where Jessica's earlier warning about keep your maintenance cost under control came back to bite us. Because we had built specifics, because we had not focused as much as we should have on keeping our maintenance under control, all of those things came back and bit us when we were trying to refactor. So the first thing we had to do was create space and time for the organization to actually do the refactor. And the only way to create space and time to refactor is to actually drop customer requests from the go-to-market side on the floor, which is, again, as I mentioned, very painful. And then we swapped it. We started swapping the architecture to move it from continuous to— from batch to continuous processing, just to keep up with the rate of growth. The batch times were running so long that we were actually falling behind on a continuous basis. So we had to switch it to stream processing. And here were the core learnings. This is exactly what Jessica mentioned, which we had followed her advice, we probably wouldn't be in this, in this space right now. We had to make the painful cuts now, and we had to reset expectations fast. It is painful, but get the pain over with early, right? And make sure that you set expectations that whatever estimate you give, when you start really digging in, it will probably take twice as long. My figure of— my figure of merit here is double the time you estimated and switch it to the next higher unit. If you said it will take 1 week, switch it to 2 weeks and then move it to the next unit of time, which is 2 months, right? I think that's a safe way. And this is the other part with Jessica. I want to reinforce her, her, her learnings. We targeted the investments on specific components. We didn't do a whole system rewrite. I think Jessica used the word, the phrase, second system. We did not fall into that trap. In this case, we identified the core systems and we are starting to rewrite it. And the second system syndrome is real because the engineers all wanted to rewrite this entire thing, which which was actually the longest part of the most contentious discussion set that we had was like, okay, should we rewrite or should we refactor? And that's kind of where we ended up. So with that, here are kind of like the 3 key takeaways. As Jessica mentioned, protect the fleet. It's super important to do capacity planning, make sure that you don't over-optimize early on. Know when to stop with the duct tape. Which I think Jessica did a better job than I did for sure. And you have to do this based on the ROI of the solution. You, you have to solve for today while making sure you can survive tomorrow. You don't have to solve for 100x immediately today because as we know, most projects don't actually get to where, where we would want them to go to. So with that, I will then say thank you everybody for taking the time to listen to us, and we will switch over to Q&A.

Awesome. Thank you, guys. Thank you, Jessica and Vijay. This is much appreciated. I know if you guys have Q&A, they're willing to take some, so feel free to put it in the Q&A at the bottom of your screen so I can ask these questions on your behalf. But in the meantime, we do have one that I wanted to ask you guys. So based on what you know, what would you do differently during your 1.0?

Jessica, I think this one's for Flex.

Okay, for, for a 1.0, I would be more considered to make sure we are matching customer needs and focusing more on a customer needs decision than on a long-term architectural view. We can get excited in engineering, and we talked about this a couple times, about solving all the things. So more validation early on in the 1.0 is probably what I would say.

Anything to add, Vijay?

I think the part where we, we would have done things differently is that instead of trying to be like agreeable and try to please everybody, we should have held the line earlier and we should have held the line stronger. In the— in our natural tendency to want to be all things to all people, I think we did the company a massive disservice by not pulling the ripcord early enough that, hey, this is an unsustainable path, simply because the design points of the system got blown away by the growth of the company. And we didn't take time to pull back and reset. So I think that was very painful. Lesson that is still ongoing.

It happened. That's what you learn from.

Yep.

We def— in regards to that question, another one that's just popped up that I think would be good is, what was your process to gather customer needs and validate them with 1.0?

So generally there, I think the important thing there is to not assume you know what the customer needs. And so yes, you may go in with a position paper, but it is to do customer interviews. It is to do direct, customer interviews of, you know, here's what we're thinking. Does this answer a problem you have? And so the risk is becoming emotionally vested in your idea, and so you need to validate it with fact.

Perfect. All right, someone did ask that, do you guys have any advice for someone in a very, very early stage startup? Uh, think, you know, 6 months, under a month old kind of thing. Infant.

Vijay?

Yeah, having come from a startup, one of the things that is super important is, I want to reiterate what Jessica said, the tendency is to overthink and over-optimize very early on. Almost by definition, right, most products are not good. Most startups are going to fail, right? So over-optimizing super for like a future, like, is— I think is over-optimizing. Focus heavily on getting product-market fit, aka somebody willing to buy your stuff and then pay you for it. If that's valid, everything else I put under the problems of success. We should all be so lucky to have problems of success. 90% of startups don't, so don't over-optimize.

Very fair. Okay, one more question before we wrap this up is, um, can you please provide more details about the second system effect that you mentioned, and then what was the key thing that helped you overcome that?

Sure, um, second system syndrome. You can actually Google it, you'll find lots of references, but it's that tendency when you've built a 1.0 or some other product and you've realized you need to do a major refactor, it's that want, not a need. It's that want to fix all the things you learned along the way and come up with a bloated solution that never makes it to the light of day. And the way you do that is what Vijay talked about. You ruthlessly prioritize the elements of your system that actually need to be touched, not the ones you want to touch, but the ones that truly need to be touched to solve the solution and continue customer adoption and revenue growth.

Perfect. Awesome. Well, thank you guys. This has been fantastic. I appreciate you guys taking the time and being a part of SAS or SCaLE. We hope to see you guys around, and I hope you guys get to attend more sessions. And everyone at home, please check out the rest of the day. I know it's been a long few days, but we're lucky to have everyone. Thank you, guys.

Thank you. Thank you, everybody.