Tag: Startup Life

Crossing the Chasm, Revisited

Sometimes there’s a single book (or movie, podcast or Broadway show) that seems to define a particular time in your life. In my professional life, Geoffrey Moore’s Crossing the Chasm has always been that book. When I started my career as VP Marketing in the 1990s, this was the absolute bible for early-stage B2B startups launching new products. Fast forward to today, and people still refer to it as a touchstone. Even as go-to-market motions have evolved and become more agile and data-driven, the need to identify a beachhead market entry point and solve early-adopter pain points fully before expanding to the mainstream market has remained relevant and true. I still use the positioning framework for every new product and company.

The gap between early adopters and early majority

Graphic from “Crossing the Chasm” showing the gap between early adopters and early majority. Image source: Patel, Neeral & Patlas, Michael & Mafeld, Sebastian. (2020). 

 

Recently while hosting the Causely team at their beautiful new offices for our quarterly meetup, our investors at 645 Ventures gave everyone a copy of the latest edition of Crossing the Chasm. It was an opportunity for me to review the basic concepts. Re-reading it brought back years of memories of startups past and made me think about the book in a new context: how have Moore’s fundamental arguments withstood the decades of technology trends I’ve experienced personally? Specifically, what does “crossing the chasm” actually mean when new product adoption can be so different from one technology shift to another?

A Quick Refresher

One of Moore’s key insights is that innovators and early adopters are willing to try to a new product and work with a new company because it meets some specific needs – innovators love being first to try cool things, and early adopters see new technology as a way to solve problems not currently being met by existing providers. These innovators/early adopters then share their experiences with others in their organizations and industries, who trust and respect their knowledge. This allows the company to reach a broader market over time, cross the chasm and begin adoption by the early majority. Many years can go by during this process, much venture funding will be spent, and still the company may only have penetrated a small percent of the market. Only years later (and with many twists and turns) will the company reach the late majority and finally the laggards.

The Chasm Looks Different Over Time

Netezza and Data Warehousing

I started to think about this in terms of technology shifts that I’ve lived through. Earlier in my career I had the good fortune to be part of a company that crossed the chasm: Netezza. We built a data warehousing system that was 100x the performance of existing solutions from IBM and Oracle, at half the cost. While this was clearly a breakthrough product, the data warehousing industry had not changed in any meaningful way for over a decade and the database admins who ran the existing solutions were in no rush to try something new or different, for all the usual reasons. Within 10 years we created a new category, the “data warehouse appliance.” We gained traction first with some true innovators and then with early adopters who brought the product into their data centers, proved the value and then used it more widely as a platform. However, “crossing the chasm” took many more years – we had a couple of hundred customers at the time of IPO – and only once the company was acquired by IBM did more mainstream adopters become ready to buy (since no one ever gets fired for buying IBM, etc). The product was so good that it remained in the market for over 20 years until the cloud revolution changed things, but it’s hard to argue that it ever gained broad market adoption compared with more traditional data warehouses.

Datadog and Cloud Observability

A second example, which is closer to the market my current company operates in, is Datadog in the observability space. Fueled by the cloud computing revolution (which itself was in the process of crossing the chasm when Datadog was founded in 2010), Datadog rode the new technology wave and solved old problems of IT operations management for new cloud-based applications. While this is not necessarily creating a new category, the company moved very quickly from early cloud innovators and adopters to mainstream customers, rocketing to around $1B in revenues in 10 years. What’s more impressive is that Datadog has become the de facto standard for cloud application observability; today the company has almost 30,000 customers and is still growing quickly in the “early majority” part of the observability market. Depending on which market size numbers you use, Datadog has already crossed the chasm or is well underway, with plenty of room to expand with “late majority” customers.

OpenAI and GenAI

Finally, think about the market adoption in the current GenAI revolution. 100 million users adopted ChatGPT within two months of its initial release in late 2022 and OpenAI claims that over 80% of F500 companies are already using it. No need for me to add more statistics here (e.g., comparisons vs adoptions of internet and social technologies) – it’s clear that this is one of the fastest chasm-crossings in history, although it’s not yet clear how companies plan to use the new AI products even as they adopt them. The speed and market confusion make it hard to envision what crossing the chasm will mean for mainstream adopters and how the technology will fully solve a specific set of problems.

Defining Success as You Cross

Thinking through these examples made me realize some things I hadn’t understood earlier in my career:

  • It’s easy to confuse a large financial outcome (through IPO or acquisition) with “crossing the chasm”, since the assumption is often that you’ve had enough market success for the outcome. In fact, these are not necessarily related issues. It’s possible to have a large $ acquisition or even a successful IPO (as Netezza did) without having yet crossed to mainstream adoption.
  • The market and technology trends that surround and support a new company and product can lead to very different experiences in crossing the chasm: You can have a breakthrough and exciting product in a slow-moving market without major technology tailwinds (e.g., data warehousing in the early 2000s) but you can also have a huge tailwind like cloud computing that drives a new product to more mainstream adoption within 10 years (e.g., Datadog’s cloud-based observability). Or you can have a hyper-growth technology shift like GenAI that shrinks the entire process into a few years, leaving the early and mainstream adopters jumbled together and trying to determine how to turn the new products into something truly useful.
  • It can be hard to tell if you’ve really crossed the chasm since people think of many metrics that indicate adoption: % of customers in the total addressable market (Moore defines a bell curve with percentages for each stage, but I’ve rarely seen people use these strictly), number of monthly active users, revenue market share, penetration within enterprise accounts, etc. Also at the early majority phase, the company can see so much excitement from early customers and analysts (“We’re a leader in the Gartner Magic Quadrant!”) that founders can confuse market awareness and marketing “noise” with true adoption by customers that are waiting for more proof points and additional product capabilities that weren’t as critical for the early adopters. It’s important to keep your eye on these requirements to avoid stalling out once you’ve reached the other side of the chasm.

I would love to hear from other founders who have made this journey! Please share your thoughts on lessons learned and how you’re thinking about the chasm in the new AI-centric world.


 

Related Resources

Building Startup Culture Isn’t Like It Used To Be

When does culture get established in a startup? I’d say the company’s DNA is set during the first year or two, and the founding team should do everything possible to make this culture intentional vs a series of disconnected decisions. Over the years, I’ve seen many great startup cultures that led to successful products and outcomes (and others that were hobbled from the beginning by poor DNA). However, as we plan for our upcoming Causely quarterly team meetup in New York City, I’m struck by how things have changed in culture-building since my previous ventures.

Startup culture used to happen organically

Back in the day, we took a small office space, gathered the initial team and started designing and building. Our first few months were often in the incubator space at one of our early investors. This was a fun and formative experience, at least until we got big enough to be kicked out (“you’re funded, now get your own space!”). Sitting with a small group crowded around a table and sharing ideas with each other on all topics may not have been very comfortable or even efficient. But it did create a foundational culture based on jokes, stories and decisions we would refer back to for years to come. Also, it established the extremely open and non-hierarchical cultural norms we wanted to encourage as we added people.

Once we hit initial critical mass and needed more space for breakouts or private discussions, it was off to the Boston real estate market to see what could possibly be both affordable and reasonable for commutes. The more basic the space, the better in many ways, since it emphasized the need to run lean and spend money only on the things that mattered – hiring, engineering tools, early sales and marketing investments, etc. But most important was to spend on things that would encourage the team to get to know each other and build trust. Lunches, dinners, parties, local activities were all important, as was having the right snacks, drinks and games in the kitchen area to encourage people to hang out together (it’s amazing how much the snacks matter).

Building culture in a startup requires in-person get-togethers

The new normal

Fast forward to now, post-Covid and all the changes that have occurred in office space and working remotely. Causely is a remote-from-birth company, with people scattered around the US and a couple internationally. I would never have considered building a company this way before Covid, but when Shmuel and I decided to start the company, it just didn’t seem that big an issue anymore. We committed ourselves to making the extra effort required to build culture remotely, and talked about it frequently with the early team and investors.

PS: We’re hiring! Want to help shape the Causely culture? Check out our open roles.

In my experiences hanging out with the local Boston tech community and hearing stories from other entrepreneurs, I’ve noticed some of the following trends (which I believe are typical for the startup world):

  • Most companies have one or more offices that people come to weekly, but not daily; attendance varies by team and is tied to days of the week that the team is gathering for meetings or planning. Peak days are Tues-Thurs but even then, attendance may vary widely.
  • Senior managers show up more frequently to encourage their teams to come in, but they don’t typically enforce scheduling.
  • The office has become more a place to build social and mentoring relationships and less about getting work done, which may honestly be more efficient from home.
  • Employees like to come in, and more junior staff in particular benefit from in-person interaction with peers and managers, as well as having a separate workspace from their living space. But the flexibility of working remotely is very hard to give up and is something people value.
  • Gathering the entire company together regularly (and smaller groups in local offices/meetups) is much more important than it used to be for creating a company-wide culture and helping people build relationships with others in different teams and functional areas.

Given this new normal, I’ve been wondering where this takes us for the next generation of startup companies. It matters to me that people have a shared sense of the company’s vision and feel bound to each other on a company mission. Without this, joining a startup loses a big element of its appeal and it becomes harder to do the challenging, creative, exhausting and sometimes nutty things it takes to launch and scale. There are only so many hours anyone can spend on Zoom before fatigue sets in. And it’s harder to have the casual and serendipitous exchanges that used to generate new ideas and energize long-running brainstorming discussions.

Know where you want to go before you start

Building culture in the current startup world requires intention. Here are some things I think are critical to doing this well. I would love to hear about things that are working for other entrepreneurs!

  1. Founders: spend more time sharing your vision on team calls and 1:1 with new hires – this is the “glue” that holds the company together.
  2. Managers: schedule more frequent open-ended, 1:1 calls to chat about what’s on people’s minds and hear ideas on any topic. Leave open blocks of time on your weekly calendar so people can “drop by” for a “visit.”
  3. Encourage local meetups as often as practical – make it easy for local teams to get together where and when they want.
  4. Invest in your all-team meetups, and make these as fun and engaging as possible. (We’ve tried packed agendas with all-day presentations and realized that this was too much scheduling). Leave time for casual hangouts and open discussions while people are working or catching up on email/Slack.
  5. Do even more sharing of information about the company updates and priorities – there’s no way for people to hear these informally, so more communications are needed and repetition is good 🙂
  6. Encourage newer/younger employees to share their work and ideas with the rest of the team – it’s too easy for them to lack feedback or mentoring and to lose engagement.
  7. Consider what you will do in an urgent situation that requires team coordination: simulations and reviews of processes are much more important than in the past.

There’s no silver bullet to building great company culture, but instead a wide range of approaches that need to be tried and tested iteratively. These approaches also change as the company grows – building cross-functional knowledge and creativity requires all the above but even more leadership by the founders and management team (and a commitment to traveling regularly between locations to share knowledge). Recruiting, already such a critical element of building culture, now has an added dimension: will the person being hired succeed in this particular culture without many of the supporting structures they used to have? Will they thrive and help build bridges between roles and teams?

It’s easy to lose sight of the overall picture and trends amidst the day-to-day urgency, so it’s important to take a moment when you’re starting the company to actually write down what you want your company culture to be. Then check it as you grow and make updates as you see what’s working and where there are gaps. The founding team still sets the direction, but today more explicit and creative efforts are needed to stay on track and create a cultural “mesh” that scales.


Related reading

Are you ready to eat your own dogfood?

Photo by Design Wala on Unsplash

It’s a truism of all cloud SaaS companies that we should run our businesses on our own technology. After all, if this technology is so valuable and innovative that customers with dozens of existing vendors, tools and processes need to adopt the new offering, shouldn’t the startup use it internally as well? It also seems obvious that a new company should reality check the value it’s claiming to provide to the industry by seeing it first-hand, and that any major gaps should ideally be experienced first by the home team rather than inflicting these on customers.

Sometimes it’s easier said than done.

It can be surprising how difficult this sometimes turns out to be for new companies.

When the technical and product teams focus on the ideal customer profile and likely user, it’s not always the case that these match the startup’s internal situation. Very often, the intended user is really part of a larger team that interacts with other teams in a complex set of processes and relationships, and the realistic environment that the new product will face is far larger and more diverse than anything a startup would have internally. This makes it difficult to apply the new technology in a meaningful way and can also make the value proposition less obvious.

For example, if a major claim of the innovation is to simplify complex, manual or legacy processes, or to reduce wasteful spending through optimization, these benefits may be less obvious in a smaller/newer company environment. As a result, the “eat your own dogfood” claim may be just a marketing slogan without real meaning.

And then there’s the other truism to consider: the cobbler’s children often have no shoes. When a startup is running fast and focused on building innovation – with a small team that prioritizes the core value of a new product and customer engagement over any internal efforts – it’s easy to push off eating your own dogfood for another day. Ironically, if there are challenges in using the product internally, these may not be seen as the highest priority to fix or improve, vs. the urgent customer-facing ones that are tied to adoption and revenue. It’s always easy to say, “Well, customers haven’t seen these issues yet, so it’s probably ok for now.”

But, in fact, this is at the heart of the innovation process.

No one cares more about your product than the team that built it. You’re always challenging yourself:

Is it really easy to use?

Does it work reliably

Where are the hidden “gotchas”?

But for a breakthrough new product, this isn’t enough.

As your earliest design partners start testing the product in their environments, it’s equally important to consider how you will use it internally as well. This is not just about testing for bugs or functionality as you build your software development processes. It’s about becoming the user in every way possible and seeing the product through their eyes and daily jobs.

The world can look quite different from this viewpoint. Using the product internally raises the bar higher than responding to customer feedback or watching them during usability testing. It gives you a direct, visceral reaction to your own product:

Does it delight you as a user?

Would you use it on a daily basis?

Does it make your job easier?

Does it provide value that’s beyond other products you’re currently using?

Even if your company is not a perfect match with your ICP and your employees are not the typical users, you can still learn a great deal. For example:

  • Do a job that your customer would do, from end to end, and see whether the product made your work easier/better.
  • Show someone else in your company (who’s less familiar with the product) an output from the product and ask if this was helpful and understandable.
  • Think of what you’d want your product to do next if you were a paying customer and considering a renewal.

At Causely, we decided early on that a high priority was to run “Causely on Causely.” Since we are developing our own SaaS application (which of course is not nearly as complex or mature as our customers’ application environments, but still has many of the same potential cloud-native problems and failure scenarios), we also need to troubleshoot when things go wrong. So we wanted to make sure that Causely would automatically identify our own emerging issues, root cause them correctly, remediate them faster and prevent end-user impact. We judge our progress based on whether WE would find this compelling and validate the claims we are making to customers, such as enabling them to have healthier, more resilient applications without human troubleshooting.

As a team, this requires us to discuss our own experiences as a customer and makes it easier to imagine the experiences of larger, inter-connected teams of users running massive applications at scale. Eating our own dogfood helps us improve the product so it’s  easier to use, more understandable and reliable. And it has laid the foundation for how we will develop and operate our own applications as we scale. Of course eating your own dogfood is not a substitute for all other required approaches to testing and improving the product, but it’s a critical element in a startup’s development that should be hard-wired into company culture.

I would love to hear about other founders’ dog-fooding experiences and what’s worked well (or not) as you build your products. Please share!


Related resources

Don’t Forget These 3 Things When Starting a Cloud Venture

I’ve been in the cloud since 2008. These were the early days of enterprise cloud adoption and the very beginning of hybrid cloud, which to this day remains the dominant form of enterprise cloud usage. Startups that deliver breakthrough infrastructure technology to enterprise customers have their own dynamic (which differs from consumer-focused companies), and although the plots may differ, the basic storylines stay the same. I’ve learned from several startup experiences (and a fair share of battle scars) there are several things you should start planning for right from the beginning of a new venture.

These aren’t the critical ones you’re probably already doing, such as selecting a good initial investor, building a strong early team and culture, speaking with as many early customers as possible to find product-market fit (PMF), etc.

Instead, here are three of the less-known but equally important things you should prioritize in your first years of building a company.

1. Build your early customer advisor relationships

As always, begin with the customer. Of course you will cast a wide net in early customer validation and market research efforts to refine your ideal customer profile (ICP) and customer persona(s). But as you’re iterating on this, you also want to build stronger relationships with a small group of customers who provide more intensive and strategic input. Often these early customers become part of a more formal customer advisory board, but even before this, you want to have an ongoing dialog with them 1:1 as you’re thinking through your product strategy.

These customers are strategic thinkers who love new technologies and startups. They may be senior execs but not necessarily – they are typically the people who think about how to bring innovation into their complex enterprise organizations and enjoy acting as “sherpas” to guide entrepreneurs on making their products and companies more valuable. I can remember the names of all the customer advisors from my previous companies and they have had an enormous impact on how things progressed. So beyond getting initial input and then focusing only on sales opportunities, build advisor relationships that are based on sharing vision and strategy, with open dialogue about what’s working/not working and where you want to take the company. Take the time to develop these relationships and share more deeply with these advisors.

2. Begin your patent work

Many B2B and especially infrastructure-oriented startups have meaningful IP that is the foundation of their companies and products. Patenting this IP requires the founding engineering team to spend significant time documenting the core innovation and its uniqueness, and the legal fees can run to thousands of dollars. As a result, there’s often a desire to hold off filing patents until the company is farther along and has raised more capital. Also, the core innovation may change as the company gets further into the market and founders realize more precisely what the truly valuable technology includes – or even if the original claims are not aligned with PMF.

However, it’s important to begin documenting your thinking early, as the company and development process are unfolding, so you have a written record and are prepared for the legal work ahead. In the end, the real value patent(s) provide for startups is less about protecting your IP from other larger players — who will always have more lawyers and money than you do and will be willing to take legal action to protect their own patent portfolios or keep your technology off-market — than it is about capturing the value of your innovation for future funding and M&A scenarios, and as a way to show larger players that you’ve taken steps to protect your IP and innovation during buy-out. In the US, a one year clock for filing the initial patent (frequently with a provisional patent filed first to preserve an early filing date) begins ticking upon external disclosure, such as when you launch your product, and you don’t want to address these issues in a rush. It’s important to get legal advice early on about whether you have something patentable, how much work it will be to write up the patent application, who will be named as inventors, and whether you want to file in more than one country.

3. Start your SOC2 process as you’re building MVP

Yes, SOC2. Not very sexy but as time has gone by, it’s become absolute table stakes for enabling early-adopter customers to test your initial product, even in a dev/test environment. In the past, it was possible to find a champion who loves new technology to “unofficially” test your early product since s/he was respected and trusted by their organizations to bring in great, new stuff. But as cloud and SaaS have matured and become so widespread at enterprise customers, the companies that provide these services – even to other startups – are requiring ALL their potential vendors to keep them aligned with their own SOC2 requirements. It’s like a ladder of compliance that is built on each vendor supporting the vendors and customers above them. There is typically a new vendor onboarding process and security review, even for testing out a new product, and these are more consistently enforced than in the past.

As a result, it has become more urgent to start your SOC2 process right away, so you can say you’re underway even as you’re building your minimum viable product (MVP) and development processes. Although it’s much easier now to automate and track SOC2 processes and prepare for the audit (this is my third time doing this, and it is far less manual than in the past) – if you launch your product and then go back later to set up security/compliance policies and processes, it will be much harder, more complicated and under much more pressure from your sales teams to be able to check this box.

There’s no question that other must-dos should be added to the above list (and it would be great to hear from other founders on this). With so many things to consider, it’s hard to prioritize in the early days and sometimes the less obvious things can be pushed for “later”. But as I build my latest cloud venture, Causely, I’ve kept these 3 priorities top of mind since I know how important they are to lay a strong foundation for growth.


Related resources

All Sides of the Table

Reflecting on the boardroom dynamics that truly matter

This past month has been an eventful one. Like everyone in the tech world, I’m riveted by the drama unfolding at OpenAI, wondering how the board and CEO created such an extreme situation. I’ve been thinking a lot about board dynamics – and how different things look as a founder/CEO vs board member, especially at very different stages of company growth.

Closer to home and far less dramatic, last week we had our quarterly Causely team meetup in NYC, including our first in-person board meeting with 645 Ventures, Amity Ventures and Cervin Ventures. As a remote company, it was great to actually sit together in one room and discuss company and product strategy, including a demo of our latest iteration of the Causely product. Getting aligned and hearing the board’s input was truly helpful as we plan for 2024.

Also in the past month, my board experiences at Corvus Insurance and Chase Corporation came to an end. Corvus (a late-stage insurtech) announced it’s being acquired by Travelers Insurance for $435M, and Chase (a 75-year old manufacturing company) closed its acquisition by KKR for $1.3B. These exits were the culmination of years of work by the management teams (and support of their boards) to create significant shareholder value.

Each of these experiences has shown me models of board interaction and highlighted how critical it is for board members to build trust with the CEO and each other. I thought I’d share some thoughts on the most valuable traits or contributions a board member can offer, and what executives should look for in board members that will make a meaningful impact on the business, depending on the stage and size of the company.

From the startup CEO/founder view

As a founder who’s built and managed my own boards for the past 15 years, I’ve learned a lot about what kinds of board members are most impactful and productive for early-stage life. Here are a few examples of what these board members do: 

  • They get hands-on to provide real value through introductions to design partners, customers and potential key hires. 
  • They ask the operational questions relevant for the company’s current stage – for example, is this product decision (or hire) really the one we need to make now, while we are trying to validate product market fit, or can it be deferred? 
  • They hold the CEO accountable and keep board discussions focused, by asking questions like, “Ellen, are we actually talking about the topic that keeps you up at night?!”
  • They don’t project concerns from other companies or past experiences that might be irrelevant.
  • They stay calm through ends-of-quarters and acquisition processes, and balance the needs of investors and common shareholders.

From the board view

As an independent board member, I now appreciate these board members even more. It can be hard to step back from the operational role (“What do I need to do next?”) and provide guidance and support, sometimes just by asking the right question at the right moment in a board meeting. I find it very helpful to check in with the CEO and other board members before any official meeting, so I understand where the “hot” issues are and what decisions need to be made as a group. 

In a public company, the challenge is even greater. The independent board member must maintain this same operator/advisor perspective, but also weigh decisions as they relate to corporate governance and enterprise risk management across a wide range of products, markets and countries. For example, how fast can management drive product innovation which may cause new cyber risk or data management concerns? And unlike in private and early-stage companies, which tend to focus almost entirely on top-line growth, what is the right balance of growth vs profitability for the more mature public company?

Building trust is key

As the recent chaos at OpenAI shows (albeit in an extreme way), strong board relationships and ongoing communications between the board and management are critical. 

If you’re building a company and/or adding new board seats, think about what a new board member should bring to the table that will help you reach the next phase of growth and major milestones — and stay laser-focused on finding someone that meets your criteria. 

If you’re considering serving on the board of a company, think about what kinds of companies you’re best suited to help, and find one where you can work closely with the CEO and where existing board members will complement your skill set and experience.  

Regardless of which side of the table you’re on, take the time to build strong relationships and trust. Lead directors, who have taken a more central role in the past several years, can ensure that communications don’t break down. But even in earlier stage companies, it’s the job of everyone around the table to make sure there’s clarity on the key strategic issues the company is facing, and to provide the support that the CEO and management need to make the best decisions for the business.


Related reading

Why do this startup thing all over again? Our reasons for creating Causely

Why be a serial entrepreneur?

It’s a question that my co-founder, Shmuel, and I are asked many times. Both of us have been to this rodeo twice before – Shmuel, with SMARTS and Turbonomic, myself with ClearSky Data and CloudSwitch. There are all the usual reasons, including love of hard challenges, creation of game-changing products and working with teams and customers who inspire you. And of course there’s more than a small share of insanity (or as one of our founding engineers, Endre Sara, might call it, an addiction to Sisyphean tasks?) 

I’ve been pondering this as we build our new venture, Causely. The motivation behind Causely was a long-standing goal of Shmuel’s to tackle a problem he’s addressed in both previous companies, but still feels is unresolved: How to remove the burden of human troubleshooting from the IT industry? (Shmuel is not interested in solving small problems.) 

 Although there are tools galore and so much data being gathered that it takes data lakes to manage it all, at the heart of the IT industry there is a central problem that hasn’t fundamentally changed in decades. When humans try to determine the root cause of things that make applications slow down or break, they rely on the (often specific) expertise of people on their teams. And the scale, complexity and rate of change of their application environments will always grow faster than humans can keep up.   

I saw this during my time at AWS, while I was running some global cloud storage services. No matter how incredible the people were, how well-architected the services, or robust the mechanisms and tools – when things went wrong (usually at 3 am) it always came down to having the right people online at that moment to figure out what was really happening. Much of the human effort went into stabilizing things asap for customers and then digging in for days (or longer) to understand what had happened  

When Peter Bell, our founding investor at Amity Ventures, originally introduced me and Shmuel, it was clear that Shmuel had the answer to this never-ending cycle of applications changing, scaling, breaking, requiring human troubleshooting, writing post-mortems… and starting all over again. He was thinking about the problem from the perspective of what’s actually missing: the ability to capture causality in software. AI and ML technologies are advancing beyond our wildest dreams, but they are still challenged by the inability to automate causation (vs correlation, which they do quite well). By building a causal AI platform that can tackle this huge challenge, we believe Causely can eliminate the need for humans to keep pushing the same rocks up the same hills. 

So why do this startup thing all over again?

Because for each new venture there’s always been a big, messy problem that needs to be fixed. One that requires a solution that’s never been done before, that will be exciting to build with smart, creative people. 

And so today, we announce funding for Causely and the opening of our Early Access program for initial users. We’ve been quietly designing and building for the past year, working with some awesome design partners. We’re thrilled to have 645 Ventures join us on this journey and are already seeing the impact of support from Aaron, Vardan and the team. We also welcome new investors Glasswing Ventures and Tau Ventures. We hope early users will love the Causely premise and early version of the product and give us the input we need to build something that truly changes how applications are built and operated.

Please take a look and let us know your thoughts. 

Learn more