5 Things You Need to Know to Create a Successful App or SaaS, with Brandon Heller of Forward Networks

Data can have tremendous and unexpected value. Some of the most valuable interactions for us never yielded a customer but yielded critical technical insights. With one service provider network, we deployed for months, but never reached the right people to expand adoption, and were not able to expand the deal. Without this interaction, we’d have taken much longer to get to a product that supports our largest customers, like Goldman Sachs, which has deployed at a scale of roughly 15,000 (!) core network devices.

Brandon Heller is the co-founder and CTO of Forward Networks. He received his PhD in Computer Science from Stanford after helping bring Software-Defined Networking to prominence via systems, demos, and specifications. Now at Forward, he leads a team of uniquely talented engineers who are making network verification not just possible, but scalable, usable, and integrate-able for every network operations team.

Thank you so much for joining us! Our readers would love to “get to know you” a bit better. Can you tell us a bit about your ‘backstory’ and how you got started?

The short version is that I’m always looking to build things, especially things based on interesting technology. I have an engineering background that covers mechanical, electrical, computer stuff, and I always like projects that combine many of those, like building a race car or robot or computer-controlled dancefloor. The intense projects with capable teams are the ones I always look back on with fondness.

Around the end of undergrad days, I started trying out the business side, with business pitch competitions. There’s something exciting and terrifying about getting in front of people you’ve never met and selling them your concept. It’s completely different than engineering. It’s about conveying the ‘what it is’ and the ‘why they should care’ questions, not the ‘how it works’, but it’s about doing all that with time and word efficiency of good technical writing. It’s ruthless, but you iterate on a concept until you get it right.

I took a class right before graduating that mixed the business and engineering sides, half-and-half, and that experience pushed me to consider joining or forming a startup, after going far enough with one concept to even pitch a cleantech idea to the CEO of Wal-Mart in the “Wal-Mart stadium”, at their headquarters in Bentonville, Arkansas.

I ended up putting the business side on hold to pursue a PhD but chose a place with an active entrepreneurship community: Silicon Valley. After driving west for three days, I spent my first weekend in California by going to Santa Cruz and surfing. Hanging out in the waves next to me, two people who I had never met before were exchanging their information and talking about their startups. Let’s just say, I knew this was the place.

Fast forward to 2020, and now I’m fortunate to lead engineering at a startup transforming the way network operations are done at the largest enterprises, with some of the best customers, funders, and teammates I could imagine.

What was the “Aha Moment” that led you to think of the idea for your current company? Can you share that story with us?

It’s a bit of a long story, but it flows naturally. The month I started grad school in Computer Science at Stanford in 2007, my lab was given a bold goal: to make networking researchers relevant again. The idea was to enable anyone — from garage tinkerers, to telecom operators, to web-giant software developers — to do something new and meaningful with networking equipment they already had. For example, imagine demonstrating a Wi-Fi network as continuously connected as a cell network, a new kind of internet firewall, or (in my case) a network that would actively minimize its energy consumption.

But how could we enable all this? With a protocol that enabled “remote control” of networking forwarding boxes, like switches and routers, called OpenFlow. From a technical standpoint, it wasn’t that interesting, but from a possibility’s standpoint, it was empowering. So, after most of us spent a summer integrating this stuff into real boxes at real Silicon Valley networking companies (like Cisco), it became our job as students in the McKeown lab to demonstrate those possibilities. Beyond demos and open-source systems, we were tasked with operationalizing OpenFlow. That meant running our research group’s network on it, as well as some of our research atop a 160-node cluster that Google generously provided us.

In the process, we gained empathy for operators. Every change seemed to break something new for us, and it was always painful to get the most basic visibility into what was happening, let alone get ahead of the issues. Yet talking to actual network operators, we learned that in contrast, we had it easy! The complexity of even a mid-size network completely dwarfed the tiny network we were operating, and it was common to still operate ancient equipment. Somehow, network operators were keeping their network running, by depending heavily on acquired skills and low-level, time-consuming interactions with individual devices.

Around this time, one of our founders, Peyman, had effectively invented a way to take any network and use math to model it, so that you could get deep visibility into the questions of connectivity that are so fundamental to effective network operations — for example, “How do packets get from A to B,” or “Can A even talk to B,” or “A and B are really important; are there multiple paths ready to go, in case one fails?” Peyman’s method, called Header Space Analysis, was the first scalable “network algebra”, and it showed all kinds of promise. We put two and two together, as here was a way to make any network more manageable, and you could imagine that nearly every Fortune 500 company out there with a network would want this for the network — because they depend upon it for their business.

The next steps were to incorporate, start building the product, and start expanding the team.

Can you tell us a story about the hard times that you faced when you first started your journey? Did you ever consider giving up? Where did you get the drive to continue even though things were so hard?

A few years in, we were making good progress: Proof of Concepts (POCs) were showing potential customers how they could now understand a network at a behavioral level and even automatically identify issues. But when going down the sales path with one particular enterprise, which we had recently done a cloud hosted PoC, the security process revealed something… interesting.

Simply put, they couldn’t deploy it, because the security team dictated that “network data has to stay in the network”. We had missed something that felt basic but is fundamental to enterprise sales: the customer must be able to deploy your software in a way that meets their security and compliance requirements. They weren’t the only ones with stringent requirements either.

That day was a bit of a low point; we had wanted to offer our product as SaaS-only. After escalating the choice all the way to our board of directors, we bit the bullet and packaged up the same code, but as a virtual appliance. This choice put all other product improvements on hold for months, but in hindsight, this was the best thing we could have done, and we should have done it sooner.

Fortunately, it was more of a small turn than a full pivot. If this ends up being the biggest “pivot”, we’ll be doing well!

So, how are things going today? How did your grit and resilience lead to your eventual success?

Today, the business, engineering, product, and even marketing sides have all developed beyond what we could have imagined. The rate of growth alone is crazy enough; for example, we onboarded four people in a day — which roughly matches the size of the company we had for a full year in the beginning. And this is the third time in the last few months that has happened! I can’t even imagine what it’s going to be like a few years from now.

As for grit, we were fortunate enough to start a company with people who had worked together in highly stressful situations — like late at night, with unmovable paper and demo deadlines — and I knew their ability to stay cool and get things done would come in handy, along with having already established trust.

Yet in hindsight, we had a deep naivete about how much other stuff would present challenges — not just technically (our bread and butter), but about the market, the sales process to effectively reach it, and how to grow the team to get there on schedule. Everyone experiences this, and the rewarding paths in life all require a grind of some kind. It’s much easier to get through that grind when you’re surrounded by people you respect and trust. I’m not going to give up when some of my best friends (co-founders and early employees) depend on me, and I trust others to share that dedication.

Today, in at least one interview for every potential new employee, we look for evidence that someone will do what it takes to solve the inevitable challenges that will come up. For example, have they stepped outside their job responsibility before, even if it wasn’t in their core expertise? Can they talk about hard problems they had to solve, and did they come out wiser and stronger? These are things you can look for, and they matter if you want to keep a culture like this, as a business grows rapidly.

Can you share a story about the funniest mistake you made when you were first starting? Can you tell us what lessons or ‘takeaways’ you learned from that?

A few months in, we had lined up an interview with a promising candidate who came highly recommended, and we wanted the interview experience to be awesome.

The interviewee arrived bright and early, but there was one little problem. Sunday night was an especially cold one, and the building heating system had failed. So, on Monday morning, it’s in the 40s indoors, and with everyone with all their jackets on, we’re trying to do a whiteboard interview while shivering, with numb fingers. Let’s just say it didn’t go well. We had effectively associated pain with the experience of working here!

It worked out in the end. That engineer who we interviewed recently celebrated his six-year work anniversary. Not only did we get a good story out of his interview; we added an engineer who was critical to where we are now.

The lesson here isn’t to have a space heater ready if you work in an old building (although that’s a good idea!); it’s to be prepared for anything. When giving a demo in front of a customer, we’ve had laptops randomly reboot, we’ve arrived to find Wi-Fi that simply won’t connect, or we’ve had an intentional site update caused a product crash at the worst possible time in front of a key customer. Murphy’s law is real, and if it matters, we’ll have a Plan B, or C, or even D sometimes.

What do you think makes your company stand out? Can you share a story?

One attribute of Forward that I’m lucky enough to experience is the uniquely deep and self-directed engineering culture. As head of Engineering, I’m responsible for making sure that we deliver the product right and respond quickly and professionally, addressing issues customers see in the field. With me are team leaders who work best when given clear goals and priorities, rather than needing specific actions and micromanagement. That culture percolates down to every engineer, and many of our engineers are rare, “one of a small number of people in the world with those skills” types.

Recently, we had a challenge with a product feature (“find issues in your network”) that was taking up too much engineering time for small improvements. Every time a customer wanted to find a new type of network issue, in a way that was specific to their environment, they needed us to implement it. It would take weeks to months to get these custom features out.

One of the engineers on the team, Andi, had implemented some of those small fixes and saw a better way: to enable customers to define their own tests on the data already there. Luckily, Andi is one of the few people in the world who has years of experience combining programming-languages skill with the domain of networking. He came up with a kind of micro-language — called a ‘domain-specific language’ — to expose the data already in our platform back to customers in ways that they could query. This way, our engineers no longer needed to be in the loop for small checks of already-present data. In the first session with our product, a prospect could now ask (and get answers to!) custom questions about their network.

I love this example because it wasn’t something that a customer asked for quite as explicitly; it arrived organically, and it’s the kind of night-and-weekends idea that occasionally germinates when people are self-directed and capable. Within days of release, this feature started to see real customer use.

If working with these kinds of people sounds interesting, we’re hiring!

Which tips would you recommend to your colleagues in your industry to help them to thrive and not “burn out”?

At some companies, a certain level of burnout is expected, and they make that work with high churn; the company name gets the resumes in the door, and employees know that the company’s brand name will benefit them, wherever they go next.

But as a small company, every employee matter, and the last fire I want to have to put out is a critical employee leaving. As someone with directly-reporting team leaders, I try to save the weekend work and long nights for when we truly need it, and make sure the business value is clear. Make no mistake — at startup, we must put in the work it takes to make the business successful — but it doesn’t have to come with people as the cost.

Of the first 21 founders or employees, four years later, we still have 16 people. I’m proud of that, and we intend to keep the attrition rate low, now we have over 50 on staff.

None of us can achieve success without some help along the way. Is there a particular person who you are grateful towards who helped get you to where you are? Can you share a story?

Each of the four founders of Forward (say that four times fast) grew our skills at Nick McKeown’s Stanford research lab, and Nick is critical to where we are today. Nick instills a belief and a confidence in his students that their time should go to projects that matter to people — not just to publications.

We spent our time building things and bringing them to the world. We built systems with users that have outlasted our time as grad students, and source code that become the foundation for products from both startups and big companies. For example, our CEO David created code (called Beacon) which heavily influenced Cisco’s OpenDaylight product, as it showed how to make a high-performance, modular base for software that controls network. There was never a prominent paper on Beacon, but that didn’t matter. The system matters.

Later, when we sought out the initial round of angel funding to kick off Forward, we felt honored when Nick participated.

Ok thank you for all that. Now let’s shift to the main focus of this interview. Approximately how many users or subscribers does your app or software currently have? Can you share with our readers three of the main steps you’ve taken to build such a large community?

As an enterprise-focused software company, we don’t target a huge number of direct subscriptions. Instead, we target deep, meaningful interactions, where our software can become critical to network operation teams on a daily basis and at their full network scale.

Today, we have deployed single instances that span 15,000 core network devices, affect over 100 network operations team members, and help enable thousands of application developers to receive provisioned resources for their apps. In fact, most indirect users are not even aware that behind the scenes, our platform is helping to implement a service critical to their deployment workflow.

We’re on an aggressive track to expand our number and size of deployments and getting there will require not just white-glove customer support, but an internal ability to make fast product changes to support workflows that pop out as high-value, today. For example, where our engagements are generating good feedback from end-users, we place engineers directly into weekly syncs and support calls. This way, we can act even faster, and build usage even faster.

What is your monetization model? How do you monetize your community of users? Have you considered other monetization options? Why did you not use those?

Today, our focus is a subscription model (per-network-device pricing) which happens to be largely decoupled from the delivery model (in-cloud vs. on-premises). Most users are those whose enterprises have paid for access to the software or are in the midst of a trial. We’ve absolutely considered other options and will revisit these as we get more data points. Right now, what we have is simple to understand, simple to deploy, and straightforward to negotiate, and it bundles a lot of value into one single bill, by including onboarding support, technical assistance, and access to software updates which frequently add major improvements to scale, support, and features.

We have to be flexible to our customers, but this easy-to-understand model has been a good starting point for us.

Based on your experience and success, what are the five most important things one should know in order to create a very successful app or a SAAS? Please share a story or an example for each.

Here are a few suggestions:

1. Data can have tremendous and unexpected value. Some of the most valuable interactions for us never yielded a customer but yielded critical technical insights. With one service provider network, we deployed for months, but never reached the right people to expand adoption, and were not able to expand the deal. Without this interaction, we’d have taken much longer to get to a product that supports our largest customers, like Goldman Sachs, which has deployed at a scale of roughly 15,000 (!) core network devices.
2. You may not know where the users find real value, and even years into the market, you may find value that was there all along, but didn’t realize. Our example was the customers saw us as a repository of all their network data, but simply needed better ways to access it.
3. Usability matters. A strong UX team that can spend the time to understand how a user thinks and make the product better match their mental model. Recently our UX team focused on making our setup process crystal-clear, and their new design includes changes that our engineering and product team might never have considered.

You are a person of great influence. If you could start a movement that would bring the most amount of good to the most amount of people, what would that be? You never know what your idea can trigger.

Good question. Given the upcoming election, a movement to decouple the connection between money and politics seems like a good place to start. This could help to ensure that what we spend money as a society considers the longer-term view. But obviously this is not an easy thing to get started!

How can our readers follow you on social media?

I’m not super-active on social media, but my company is. Follow Forward on Twitter via @FWDnetworks, and on LinkedIn at https://www.linkedin.com/company/forward-networks.