AI has dramatically reduced the time and cost required to build software. Features that once took weeks can now be developed, tested, and deployed in days—or even hours.
That sounds like an obvious advantage. But according to Misha Makara, co-founder and CTO of Rally AI, faster development introduces a new problem: when companies can build almost anything, deciding what not to build becomes more important than engineering speed.
Misha has spent much of his career entering difficult technical situations. He has worked across cybersecurity, enterprise systems, digital securities, technical due diligence, and startup turnarounds. Venture firms have brought him into portfolio companies when products were failing, teams were struggling, or capital was running out.
Rally AI presents a different challenge. Rather than rescuing a company in crisis, Misha is helping scale a product with more than 200 prospective customers waiting to get access.
His experience offers several lessons for founders navigating AI development, product strategy, technical debt, startup pivots, and public relations.
Treat Product Development Like an Experiment
Misha’s approach to company building was shaped by one of his earliest mentors, Brad Paxton, who worked on Kodak’s pioneering digital-camera technology.
Paxton taught him that an engineer could also operate effectively as a CEO. Rather than treating business decisions as intuition-driven bets, founders can approach them through experimental design.
Every meaningful product experiment should have:
A clear hypothesis
A defined scope
A measurable outcome
A limit on the time or capital invested
A predetermined decision based on the result
The point is not simply to “fail fast.” That phrase is too vague to be useful.
Founders must decide in advance what failure looks like. Otherwise, a company can continue investing in an unsuccessful idea indefinitely, interpreting every disappointing result as a reason to add another feature, extend another deadline, or raise more capital.
A disciplined experiment creates boundaries. A team might give an engineer one afternoon to test whether a technical approach is viable. If the experiment produces the required result, the company invests further. If it fails, the team records what it learned and moves on.
Without those limits, experimentation becomes wandering.
More Features Rarely Rescue a Failing Product
One of the most common patterns Misha has seen in struggling startups is the belief that additional features will solve weak market traction.
He described a company that had raised approximately $20 million to build a government-focused alternative to DocuSign. After spending roughly $17.5 million, the business still lacked meaningful traction.
The company continued adding features. But the core issue was not product breadth. It was compliance.
The platform was not FedRAMP compliant—a major obstacle for a company selling software to the federal government.
The turnaround strategy was counterintuitive: build less.
Rather than continuing to expand the full product, the team focused on creating a compliant version with roughly 10% of the original functionality. That certification mattered more to customers than the long list of additional features.
The lesson is straightforward: founders should identify the one constraint preventing adoption before adding more functionality.
When a product is not selling, the answer is rarely “more product.” It may instead be:
A missing certification
Poor positioning
An unclear target customer
A broken distribution strategy
Weak onboarding
A lack of trust
A problem customers do not consider urgent
Building more features before identifying the real constraint simply burns runway faster.
AI Has Shifted the Software Bottleneck
Traditional software development required lengthy planning cycles. Teams conducted customer interviews, created mock-ups, validated designs, wrote requirements, and then moved into development.
Shipping a new production release every two weeks was once considered a strong operating cadence.
AI development tools have radically accelerated that process. Rally AI can sometimes deploy software nine times in a single day.
The bottleneck is no longer necessarily engineering capacity. It is product discipline.
Because features are cheaper to produce, teams can easily build things simply because they are technically possible. This creates several risks:
Product roadmaps become reactive
Teams chase new AI capabilities without customer demand
Technical debt accumulates rapidly
Customers receive unnecessary complexity
Engineering activity is mistaken for business progress
AI does not eliminate the need for customer discovery, product strategy, or thoughtful architecture. It makes those disciplines more important.
A company that moves quickly in the wrong direction does not gain an advantage. It simply reaches the wrong destination faster.
Not All Technical Debt Is Bad
Technical debt is often discussed as though it should always be eliminated. Misha argues that the more useful distinction is between productive and unproductive debt.
He shared the example of a client that wanted a sophisticated free-shipping system. The request sounded simple but quickly expanded into a complicated set of rules involving eligible products, bundles, promotions, and administrative controls.
The development team built extensive infrastructure to avoid creating technical debt. But the customer barely used the feature.
The company spent more building the system than it would have spent manually covering the shipping costs.
That is the wrong kind of engineering investment: technically clean, but commercially unnecessary.
Misha compares technical debt to debris left on a highway after a minor accident. Some debris can remain near the side of the road without stopping traffic. It becomes a priority only when it blocks the direction the company needs to travel.
Founders should therefore ask:
Is this debt slowing customer growth?
Does it introduce serious security or reliability risk?
Will it prevent an upcoming product change?
Is fixing it more valuable than acquiring customers?
Can the process temporarily be handled manually?
Early-stage companies should not build permanent infrastructure for problems they have not yet proven exist.
Sometimes paying someone to complete a task manually is smarter than spending months automating it.
Rally AI Wants to Become a Company’s First PR Hire
Rally AI uses artificial intelligence to help companies build relationships with journalists, influencers, and media outlets.
The platform analyzes large volumes of information to understand:
What journalists are writing about
Which topics are gaining momentum
How stories move across media channels
What performs well with specific audiences
How competing companies position themselves
Which company narratives may interest particular reporters
Rally then matches a company’s goals, news, and positioning with the media contacts most likely to care about the story.
Misha describes the system as a three-sided marketplace involving companies, media contacts, and the broader cultural or news environment.
This matters because public relations is not simply mass email outreach. It is relationship building.
A journalist does not care that a company wants coverage. The journalist cares whether the story is relevant, timely, credible, and likely to interest an audience.
Rally’s goal is to understand both sides of that equation before the company begins pitching.
The platform has already helped early-stage companies secure coverage from major publications, including The Wall Street Journal.
AI Cannot Fix an Undefined Company Story
Rally has reportedly experienced no customer churn so far, partly because the company has been selective about who it allows onto the platform.
The companies that perform best tend to understand:
Who they serve
What problem they solve
Why their approach is different
What message they want the market to remember
PR becomes much harder when a startup cannot clearly explain what it is.
AI can improve research, targeting, timing, and communication. It cannot create genuine product-market fit or manufacture a coherent identity for a company that does not have one.
Before seeking media coverage, founders should be able to answer three questions in plain language:
What does the company do?
Why does it matter now?
Why is this company uniquely positioned to solve the problem?
If those answers remain unclear, the company probably has a positioning problem—not a PR problem.
First-Mover Advantage Is Overrated
Misha is skeptical when founders describe first-mover advantage as a durable competitive moat.
History frequently rewards the second or later entrant that learns from the original innovator’s mistakes.
Kodak created the digital camera but failed to dominate digital photography. Microsoft has repeatedly entered markets after competitors and then used distribution, product integration, and iteration to win. Apple has often succeeded by refining existing product categories rather than inventing them.
The first company into a market bears the cost of educating customers, discovering failure modes, and testing business models.
Later entrants can study those lessons and build a stronger product.
A better question for founders is not, “Are we first?”
It is, “What have earlier companies misunderstood, and why are we positioned to execute differently?”
Disruption Usually Starts With One Narrow Advantage
Founders frequently describe their products as disruptive, but genuine disruptive technologies are rarely superior in every dimension at the beginning.
They are often worse in most ways while being meaningfully better in one specific area.
Early flash storage illustrates this pattern. Initial flash drives had less capacity and cost more per unit than traditional hard drives. Their critical advantage was speed.
Over time, the technology improved while preserving that advantage. Eventually, solid-state storage became commercially viable across a much broader market.
Startups should identify the one dimension where they are significantly better than incumbents.
That advantage could be:
Speed
Ease of deployment
Accessibility
Accuracy
Workflow integration
Security
A new distribution model
Performance in a narrow use case
Trying to outperform established companies on every dimension from day one is usually unrealistic.
Fractional CTOs Should Not Be Fundraising Props
Fractional CTOs can be useful when a company loses technical leadership, needs to stabilize a platform, or requires specialized expertise during a transition.
But Misha strongly warns against hiring a fractional CTO primarily to help raise capital.
Investors may question why the technical leader presented during fundraising is not committed to operating the company over the long term. That creates uncertainty around technical ownership, recruiting, intellectual property, and execution after the round closes.
A fractional CTO should solve a real operational problem.
The role can work when the mandate is clear: stop the crisis, assess the architecture, rebuild the team, transfer knowledge, and recruit a permanent replacement.
It should not be used to manufacture credibility during investor meetings.
The Central Lesson: Build Less, Learn Faster
The common thread across Misha’s experience is disciplined decision-making.
AI allows teams to build faster, but speed does not replace judgment. Founders still need to understand their customers, define their experiments, identify their most important constraints, and stop investing when evidence no longer supports the original thesis.
The strongest teams are not those that produce the most features.
They are the ones that know which features matter, which shortcuts are acceptable, which technical problems can wait, and when the company must change direction.
In Misha’s words: “Try to find a way to do less. Do the things that actually matter.”
That may be the most valuable product strategy in the age of AI.
👂🎧 Watch, listen, and follow on your favorite platform: https://tr.ee/S2ayrbx_fL
🙏 Join the conversation on your favorite social network: https://linktr.ee/theignitepodcast
Chapters:
00:01 - Introducing Misha Makara and Rally AI
00:41 - Cybersecurity Roots and Kodak’s Digital Camera Legacy
02:26 - Experimental Design for Founders and Engineers
04:10 - From Wayfair and Dell to Startup Turnarounds
05:57 - Apollo Cameras and Black-and-White Barns
07:31 - Lessons From High-Volume Venture Portfolios
09:35 - Risk Cycles, Late-Stage Liquidity, and Early-Stage Investing
14:46 - Why More Features Fail to Save Startups
17:37 - Founder Coachability and the Ability to Pivot
19:50 - Bundling Risk From Hyperscalers and AI Platforms
22:27 - Why First-Mover Advantage Is Overrated
24:20 - AI Development Speed and the New Product Bottleneck
27:07 - Good Technical Debt vs. Bad Technical Debt
30:21 - Rally AI as a Startup’s First PR Hire
32:33 - Who Rally AI Works Best For
33:47 - Measuring PR Success and Building Media Relationships
35:11 - Rally AI’s Long-Term Vision
36:12 - The Three-Sided PR Marketplace
37:41 - Second-Mover Advantage and Disruptive Technology
41:25 - High-Signal Interviewing and Hiring Engineers
43:20 - When to Hire a Fractional CTO
Transcript
Brian Bell (00:01:11.092): Hey, everyone. Welcome back to the Ignite Podcast. Today, we’re delighted to have Misha Makara on the program. He’s a co-founder and CTO of Rally AI. Before Rally, he spent 15 plus years—as a venture firms, they would call him when a startup is on fire technically—and he spent over five years at T-Zero’s SEC regulated digital securities platform. Pretty exciting. And now he’s working on Rally, which is a system that uses AI to accelerate PR. So we’re really excited to have you guys on the program. Thanks, Misha. Yes, my pleasure. What—love to start with your origin story. What’s your background? Sure.
Misha Makara (00:01:43.634): So I studied cyber security, and one of my first bosses—I went to the Rochester Institute of Technology—my first boss was Brad Paxton, who’s the guy that was in charge of the team at Kodak that created the digital camera. So, fascinating guy to have as your first boss, first mentor. I remember him pulling me into his office and going, oh, me sure, this thing just got declassified. We can talk about the cameras that we were using in Apollo and all this. It was great. Wow. So I was working for him as a as a sysadmin, doing work on truly large-scale systems. We were working on data capture systems for the census, and he saw me and one of my friends, as I was in the undergraduate program, and said, you know, you should really consider starting a business. I had really never thought of myself as a business person. I’m an engineer. He said, no, no, no, these are the same things. So one of the the most interesting things that he kind of taught me was, you know, you have this one mindset of a CEO being, you know, the Elon Musk, the Steve Jobs. But a CEO can also be an engineer and look at the business through the lens of experimental design. And that’s one of the the things I I really like to get into with you today, about how do you both set an engineering culture, and how do you design and iterate?
Brian Bell (00:02:53.669): Through product ideation. I love the Kodak story, right? Because they had the digital camera, right? And the executives—this is famous in business schools, right? Like, I have a business degree undergrads. I’m the opposite. Like, I’m not an engineer. You know, business degree and MBA. And, like, that Kodak case is, like, told over and over again in schools. You know, they literally had the digital camera, and they just, like, shelved it because it would eat their revenue, right? Like, they were afraid...
Misha Makara (00:03:19.675): To cannibalize their own cash cow. Exactly. And and Brad was the person that was literally told, you hide that in a desk drawer where no one will find. And it’s weird to think, in another universe, Kodak could have been the Google of our time. One of the things that—I don’t know if you can see it—he gave me on the way out, as when I when I finally finished the story. But yeah, he encouraged me to start a business, a web application development company, and I ended up selling it. But he used to have, right back there, that’s the page from Alice in Wonderland where Alice comes to the fork in the road and meets the Cheshire Cat. And Alice says, you know, hey, which road should I go down? And the Cheshire Cat says, well, where are you trying to get to? I don’t care so much. Then it doesn’t really matter what road you go down. And I love that. I always keep that up there because it’s okay to do pure research, and it’s okay to do applied research. But again, as a facilitator, you have to define and set your limits about how much are you willing to experiment. And it’s also okay to tell your people, we’re gonna try this, but here’s the sandbox that we’re gonna play in. And if we—we’ll either get this result, in which case we’ll go in this direction, or this other result, in this other direction, or we’ll get no result, and we’re going to have to go retry the experiment. And I think that there’s a lot of that missing in software development as a whole. And especially now, where the costs of development are so much lower with AI, there’s a lot that can be done in that, again, experimental design approach to ideation and product development. From there, I created my company, sold it, said, you know, I’d really like to work for a real company, ended up working for Wayfair.
Brian Bell (00:04:49.731): In Boston. Did—corporate agencies are kind of like halfway companies, right?
Misha Makara (00:04:53.983): Yeah, no, no one’s ever heard of that. Yeah. And then got recruited out of Wayfair by Dell and put in charge of the managed security services product line at Dell. And that was another interesting story because their—Dell loves to hire military folks, and they very much like their silos. And I created a way to get those silos to talk to each other. That got attention from the guy that signs the paychecks, and next thing I knew, I was asked to standardize that process and roll it out. So enterprise project program governance is another important topic. And then, from there, I bumped into Gangels when I was living in New York. It actually started with an argument with someone that turned out to be Paul—Paul Grossinger, who’s, uh, one of the the founders of Gangels. And he asked me to start doing technical due diligence on some of their portfolio companies. And then, inevitably, some of those companies went sideways, and they said, hey, we like this Misha fella. Is he available to help us out? And I started doing more and more. And then I’m just one of the resources that they call in whenever something goes sideways or catches fire. And that’s where I’ve been up until Rally. And Rally is really a great opportunity because I—I’m not dealing with something on fire for once. I’m dealing with something that—we have this huge backlog, 200 plus customers that are waiting to sign up. And I’ve never had that kind of a problem before, where people are bashing down the door to get in. And we’re trying very hard to do it in a way that doesn’t decrease quality. So I’m very much about the not in shittifying the the product. Yeah, results.
Brian Bell (00:06:20.352): Well, I want to get to Rally, but there’s a few story threads I want to tug on first. Absolutely. One thing that just kind of circ—circling in my mind right now is the Apollo story. Yeah. You know, what were the cameras...
Misha Makara (00:06:31.416): On Apollo that they declassified? So yeah. So he pulled me into his office one day, and he was saying, so I got to tell you this story. There was this time that Kodak—we, the team and I—we went out into the the middle of the Midwest, and we had to knock on people’s doors and say, hey, we can’t tell you who we are or where we’re from, but we just want to paint your barn black and white. You don’t get to ask any questions, but we just need to paint your—paint your board. Pros...
Brian Bell (00:06:55.906): And cons. You get a fresh coat of paint. You get a fresh coat of paint. We’re going...
Misha Makara (00:06:58.828): To give you ten thousand dollars and the—no questions. And he was like, yeah, there’s still some barns that have to be painted black and white. And do you have a guess on what those were for? No. Satellite imagery, or—yeah, you need to focus those cameras, right? So you need to have a large spot in order to be able to focus them and to calibrate them. So that’s just kind of like—you, like, calibrate...
Brian Bell (00:07:19.518): A printer, almost. Yeah, exactly. Wow. Okay, so they’re out in the Midwest painting these. There’s some farmer...
Misha Makara (00:07:25.760): You know, has a barn that was painted black and white, and now you get to know what it’s for. And were these digital cameras? And no, these—these were analog cameras. Another project that he worked on later was, when you’re in the spacecraft and you want to do photos of the moon, everything’s moving. So how do you get the film to be in synchronous with what you’re taking a photo of, so that way it doesn’t end up blurred? And go figure, a lot of those cameras and optics were used for things before the—before moon photography. The next thing I wanted...
Brian Bell (00:07:52.392): To cover is your experience helping Gangels. Gangels is one of the the highest volume shops around. Lorenzo was on the podcast, I don’t know, last year, and, you know, we kind of talked about kind of the high volume strategy, pros and cons. And we’re both, you know, in that school of thought. We’re both in the high volume school. They’re even higher volume than us. We do about a hundred a year. I think they do two or three hundred years, something like that. Now, what are some common patterns you you notice with successful and failing startups and all that? Oh, that’s a good question. Yeah, yeah. And by...
Misha Makara (00:08:25.957): The way, I’m going to say, do as I say, not as I do, because, you know, my personal investments there have been a mixed bag. I personally like to see the—again, the founders that are willing to try something, but have—they’re creating a product for an audience that they can actually define and quantify. I’m also interested to see how quickly are they willing to learn and pivot. I think that that’s an important factor in in the success. If you asked three years ago if we were going to be in kind of this AI world, I don’t think we would be able to predict it as it were. And I keep thinking about the early days of dot com, and if you were asked to pick the winners of dot com, what you would have said at that particular point in time versus who were actually the winners at the end. So I don’t have any good good advice on that. I will say it’s interesting to look at the overall market forces, and especially in election years, what happens there. I don’t know if you’ve kind of experienced that, but Gangels—yeah, there’s there’s interesting and different market forces. So investment team tends to switch from early stage and seed stuff to to later, more mature things in those years. Well, tell me—tell me more about that. I think I know what you mean, but—yeah, no, it’s just as simple as that, because Gangels is individual investors, usually invest in SPD retail, a lot...
Brian Bell (00:09:43.329): Of SPDs. They have some funds. They do a lot...
Misha Makara (00:09:45.651): Of early stage, precedence seed. Yeah, yeah, yeah. But, you know, are you willing to go, you know, putting your money on a very early stage company for, you know, an hopefully exponential return, versus putting something into, you know, a Series C...
Brian Bell (00:09:58.901): Or D, kind of. Yeah, so you’re—you’re talking about this, like, cycle of risk that happens every, you know, seven-ish years, where, you know, we all go risk on. And risk on includes, like, going really early stage. All of a sudden, early stage lights up. And what happens first—I’ve noticed this as well, and I think I’ve talked about it on the pod. I’ve been on vacation. This is my first podcast after—after Fourth of July vacation, so I’m a little little rusty, uh, shaking the cobwebs off of my my brain here. And right now, I’d say, yeah, we’re very risk on in the late stage, pre-IPO. Yeah, like, that market is very hot right now. The private market, these eight billion, ten billion, hundred billion, trillion dollar companies. But as liquidity flows through the system, um, and LPs start getting checks and and shares from SpaceX, and then I—I guess Anthropic will be next, and Open AI—I forget the order right now—but as as all that money comes into the system, all of a sudden everybody’s going to go risk on, right? Because we’ll have a bunch of liquidity, and we’ll have a bunch of capital going, wow, that 20-year bet on SpaceX really paid off. You know, you know, I was in that fund. You know, if you’re in a fund that holds SpaceX from the C to A, you’re—that LP is just, like, licking his chop chops right now. It’s just, oh man, like, that—that big—well, you know, just that position will probably—you know, there’s a lot of fun sitting out there with a huge TBPI, total value to paid in capital, that’s about to be, like, huge DPI from that—from that one deal. And it’s gonna—it’s gonna make a bunch of LPs go risk on again in the early stage.
Misha Makara (00:11:28.813): I think you’re—you’re right. I’m personally interested to see what happens after the lockup period, and especially since you have a fund, you have—you have an asset that’s now going public and will immediately become an index, right? And then you also have that because of the the SEC rule changes, and you’ve also got people that are leaving the lockup period exactly the same time. And you also have a prospectus that has some very interesting things in there, saying, you know, yeah, part of our evaluation is based on the idea that we think that we can build this, uh, you know, power distribution facilities in space in order to support our data centers. And we think that that line of business is going to be worth this, but we haven’t quite figured out market viability about it yet. You know, so I’m interested to see what’s going to happen. It’s strange times, and strange times for—for that, on—on top of rule changes. You know, it’s going to be very interesting to watch.
Brian Bell (00:12:20.650): Yeah. What are some of those? Do you recall any of the rule changes? I’d love...
Misha Makara (00:12:23.952): To—yeah. One of them was just the the lockup period of about the re—and don’t hold me to this exactly—but there’s a requirement that used to be, I want to say, several months before. It’s—yeah, it’s typically...
Brian Bell (00:12:35.419): A six-month lockup. Yeah, it’s been changed to...
Misha Makara (00:12:38.354): To a stage lockup. Yeah, yeah. I thought it was something as low as 15 days now as part of the the new change, which is why it just all of a sudden will become an index fund, because of how large those companies—yeah, that—well, that’s...
Brian Bell (00:12:52.782): The other thing is, like, indexes like the Nasdaq Triple Q have to buy the shares because—because of the market cap, because it’s part of, you know, the Nasdaq 100, the 100 largest market cap companies in the index. And I think that happened this week, actually. They—they had to buy eight billion dollars worth of—no matter what, I just have to buy it—which props up the stock, right? Because it’s like—but then also you have, I—I saw the news of the Big Short guy, yeah, is shorting the stock, right? So—and then you have, like, Kathy Wood from ARC buying the stock, right? And then you have the index. So it’s like you have all these buying...
Misha Makara (00:13:28.409): And selling forces out there. If—if you were sitting on SpaceX for 10 years, and you’re 15, 20, and you’re all of a sudden are now looking at the the current price, you know, and you’ve got a mortgage to pay, I don’t—you know, you know how this goes. And we’ve seen the pattern previously.
Brian Bell (00:13:47.526): Yeah. Typically, IPOs don’t pop like they did, you know. I think I wrote an article on this, actually, on the margin. It’s like 50-50, basically. Okay. About 50 will be, like, above par, and 50 will—50 will be below par. And then you—you have the famous famous example of, like, Facebook, right? Where they just kind of just wallowed for a couple years, and everybody’s like, oh, Facebook’s dad. This sucks. And then, of course, it just went stratospheric after that. So, interesting. Went to space. Yeah. What—yeah. And so, what what are some of these lessons as you kind of dug in? And this is an interesting technical—it’s like almost like a technical post due diligence. These startups are blailing about, and you’re kind of...
Misha Makara (00:14:26.274): Yeah, shoot it in to help them. One of the the biggest problems that I’ve seen is, you know, especially when I’m parachuted in, the goal is to—to save the company. And it’s oftentimes very difficult to pivot because the the research and the hypothesis about the market has oftentimes shifted. So, for example, I’m—but I’m thinking about one that was basically a DocuSign competitor for government. And same thing, they—they got 20 million dollars. There were 17 and a half through it, but they—they never really could get the traction. It really wasn’t quite working, and they were continuing to invest in their existing product line, right? More features. The things that’s going to save us is more features. That—that’s—that’s what’s happening. But the problem in that particular case was they weren’t Fed Ramp compliant, which is a problem if you’re trying to be a DocuSign competitor for government. So they were trying to solve it by just saying, hey, let’s throw more features at this. And the reason they didn’t go there previously was, you know, cost and uncertainty. And in that particular case, it was quite a sell to the business to say, we’re going to do less. We’re going to make a product that is compliant. That’s only 10 of the feature set of what the full product is, but it’s going to have that check mark. And through that, that’ll be the the thing. And sure enough, that was, when—when push came to shove at, you know, the end of the killer feature, that—that was the thing that they needed. And so I think a lot about Pareto and the 80-20 rule. Yeah. One of my friends always said, you know, try to find a way to do less. Do the things that actually matter, and the things that—that show. And that’s really what we’re trying to do when we’re thinking about a turnaround. What—what is—what, first of all, what did we learn? You know, you spent this money to do something. You learned something, right? And there’s oftentimes little nuggets of IP that weren’t necessarily the things that you thought were going to be the business, but can be. And so one of my kind of default maneuvers is: what are the integrations that we built? What is the data that we have? Can we monetize any of this? As kind of a general emergency, last-minute maneuver, we can usually sell an API. There’s patterns to do that. We can spin that up pretty easy. And then it’s a decision about where and how are we splitting our effort, especially when there’s very little gas left in the tank.
Brian Bell (00:16:42.077): Yeah, and there’s famous examples of that. I mean, Slack was, you know, an internal app at yet another gaming company that he tried—tried to get off the ground, right? Exactly. And same with Flicker before that. I think it, you know, it was another game, and they had a photo sharing app inside the game, and they pivoted to photo sharing. The same founder, right? Same—same team. Yeah, yeah, yeah. But again, that’s...
Misha Makara (00:17:04.669): Through listening and and figuring it out. But if you show up and they go, no, no, no, we’re a gaming company here. We’re—we’re not doing that. That’s—that’s not what I signed up for, right? That’s a difficult conversation...
Brian Bell (00:17:17.167): To have. What have you noticed about, you know, the founders who—who were able to pivot, mm-hmm, and cut their losses, versus, I guess, VCs would describe them as coachable, right? That’s the word that VCs use. Yeah, that was exactly...
Misha Makara (00:17:32.559): Where my head was going. So there’s a certain—it’s difficult when you’re doing the diligence because you’re trying both to assess coachability, but also you want them to have enough of a product thesis and direction to be able to go. You know, this—you can’t be there coaching all the time. That’s not your job. You have enough companies in your portfolio. But you also want someone that’s going to be, as I like to say, appropriately opinionated, right? You want someone that you can do what I—what I call sandcastle crushing. You can jump in and say, okay, I’m not exactly sure about this, but, let you know, if this were to happen, what—what would we do? You know, if all of a sudden Open AI were to decide that this was going to be a focus, or Uber—Uber is a great example—you know, just massive company, they’ve decided that they now want to eat your lunch. What—what are you going to do? How are you going to handle that? Amazon, you know, diapers.com, right? There’s so many things that—that you can do. And again, not—not being distracted, or having the hubris to think that you can outspend one of those companies. They will win. So how do you operate in—in that particular environment?
Brian Bell (00:18:38.546): Yeah, I call it the bundling risk, right? I was just talking to a founder about this yesterday. I was like, hey, this is really cool. You have a very cool model for memory inside of an organization, but how are you going to defend that against the hyperscalers, who already have all that data, one, and then they can just bundle it into their offering? Yeah, exactly, right? And it’s, like, core to how they operate. It’s, like, literally core to how those foundational models work, is their memory and state and all of...
Misha Makara (00:19:05.242): That. Yeah, yeah. And that’s—that’s another larger topic about the use of AI now in development. And it’s been interesting. It’s interesting to get a front row seat to how these things have developed, right? So prompt engineering, as—I’m curious to get your thoughts—prompt engineering has not disappeared, but it certainly has been suppressed and pushed into a corner. And if you’ve mastered that skill, then you do better. If you understand how orchestration works, then you do better. And I—I’m now watching a bunch of friends that are using Chat GPT specifically as Google. One asked yesterday. He was asking kind of a appointed legal question, and I said, yeah, it’s—it’s not going to do well at that. He’s like, well, it gave me an answer. I was like, yeah, but let’s—let’s actually look at the the actual regulation. And I think we got onto this topic of how AI is different and how it’s...
Brian Bell (00:19:56.517): The same, right? I think one of the threads I wanted to tug on, which I thought was great, was, you know, you—you think about the dot-com. Yes. Right? And, you know, some of the winners we thought, like AOL and Yahoo. AOL just sold, I saw. Anyway, you know, you—you would have said, oh yeah, like, why even work on a search engine? Like, Yahoo’s got that dialed, and maybe AltaVista or Lycos or Excite or—or whatever. And it turned out to be Google. And I—I wonder the same thing with the—with the models, right? It’s like, oh, it’s so clear Open AI is going to win. Or—but now it’s Anthropic, right? Well, but...
Misha Makara (00:20:27.663): But again, this is the—I’m going to say—the failure to study the history of technology. And I—I love—there’s a couple things. I’ll give you a couple secrets if you’re pitching to me and you’re asking me to do diligence. The first one is, you know, we—they say, oh, we have first mover advantage. First movers don’t usually take over the market. If you don’t believe me, look at Uber, that bought their software from someone else. And, as we all know, we’re currently using Kodak cameras for everything, right? It’s usually the second person to the field that can take advantage of the first company’s learnings to do it better a second time.
Brian Bell (00:21:00.468): Look at Microsoft. They’ve been second to market on almost everything they’ve ever done. Yeah, exactly. Like, literally second to market...
Misha Makara (00:21:06.952): In every product they have. Every—every single product. Even Windows. And I’m going to say something controversial: there’s an argument that Apple is doing the same thing, especially before the M1, right? Yeah. Right? When you were comparing, you know, one of your older iPhones to an Android way back when, the Android had better specs, but Apple did better on...
Brian Bell (00:21:25.263): The software. I’m still Android, so I’m—yeah, I am too. But yeah. Well, you’re—you’re a nerd like me, so, like, I want to be able to look in my device. It bothers me that I can’t see what’s on that other partition. Yeah, yeah, exactly. What do you—I can’t get...
Misha Makara (00:21:37.581): To my files. What are you talking about? Crazy. I own this device. I downloaded the file. Like, just show me where the file is. You know, if you want something really terrifying, go—go look at the actual build, and you can see the packages that are getting installed, and the companies that make those packages. You’ll go—go to their website, and it’s like, keylogger for government. Love that. Thank you. Thank you, guys. Nice. Yeah.
Brian Bell (00:21:59.778): As somebody with boots on the ground working in a startup, I mean, how does this feel different now with AI, right? I get...
Misha Makara (00:22:06.622): That question all the time, but yeah, yeah. First of all, the the velocity of software development has changed. You know, it used to be that—I was chatting with one of my my friends and colleagues about this recently—you know, you really had to get your your product specs, and you’d have to do viability testing, right? So think about your your traditional SDLC. You’d sit down with the designer. What’s an SDLC? For—sorry, sorry. Software development lifecycle. My apologies. So think about how you used to make software, right? And again, we can go back and we can talk about waterfall to agile to the new agentic development, you know, all of that. But the method, if you were being a skilled practitioner, was always the same, right? You would sit down. You would do interviews. From those interviews, you would create a design and a mock-up. If you were smart, you would take that mock-up, you would put it in front of customers, you get feedback from those customers, then you—you would build your requirements. Rinse and repeat. And then, from there, we would go off into building. And you were happy if you could turn out a build every two weeks. That was considered to be the gold standard of a successful software development lifecycle: new version of product every two. In the world of AI now, we can go so much faster. And part of the problem now is, because it’s so easy to push things out, it’s very easy to become distracted with new features and doing things just because we can rather than because we should, or because they create value for customers. Before we even get into the the cyber security side of things, it’s just a basic maintaining of discipline. And one of the things we talked about earlier is—is intentional and deliberate experimental design in the product. So it’s, as I said, it’s very easy to roll out a new feature now. It’s a lot more difficult to sit and listen, and to be strategic, and to make sure that you aren’t accumulating massive amounts of technical debt inside of the platform, and the debt that you’re accumulating is the right type of debt.
Brian Bell (00:23:57.520): Right. Yeah. And this is—I think this is a key distinction. I remember, yeah, I was a PM for a really long time, for probably eight, nine years of my career. And, you know, the the joke was, like, our—our quarterly roadmap became our four-year roadmap, right? And now it’s probably the opposite. Your, you know, quarterly roadmaps becoming your, like, I don’t know, your sprint-level roadmap, because you can really accelerate. And what I think that probably does is it removes the excuse of engineering’s bottleneck. Now, if engineering’s not the bottleneck anymore, the bottleneck really, like I think is what you’re saying, which is it’s understanding the customer and avoiding bad technical debt, right? Yeah. And—and I’d love to get into the topic of the right kind of debt versus the wrong kind of—yeah.
Misha Makara (00:24:36.218): Yeah. What do you mean by that? Yeah, yeah. So this is actually a lesson from—from Wayfair. I’m gonna go through a personal experience. One of the first projects I ever worked on at my company, we had this customer wanted the ability to do free shipping. Sounds easy. Well, certain items get free shipping, but not others. Okay, so certain items, but if they’re bundled, maybe we can do this, right? You know, it sounds like, yeah, there’s...
Brian Bell (00:24:58.636): This whole decision tree of free shipping, right?
Misha Makara (00:25:00.960): Right, right. And so then, you know, we were kind of like, well, debt is bad, so let’s, you know, let’s handle that. Like, we’ll—we’ll build an interface for this. You know, the—you know, the admin of the the site needs the ability to specify these things, and to do this and do that, and we have to build this logic, and that—meetings with the customer, and over and over. And then, ultimately, how many things were sent with free shipping, right? How many things could have just been done with a—with a promo code, right? There was a lot of infrastructure that was built that was never used and never seen, but certainly cost a lot of real money. So I would argue that that would be the bad kind of debt, right? We ended up building something to try to remove debt, but we ended up adding code that never really served a value. The customer never used it. And, in fact, the money spent on building the feature would have been better to just handle more free shipping. The—the analogy that I like to think about when I’m—what I’m teaching this is debris on the highway. So if you think about it, after an accident, there is, you know, there’s little bits of car everywhere. And, you know, if you just give it a little bit of time, sometimes—like a—like a pile up, right? Yeah, yeah, yeah. But, you know, yeah, let’s go minor accident, right?
Brian Bell (00:26:13.298): But you got—you, yeah, you got the the—the crashed cars, the wrecked cars, off the highway. And now there’s, like, debris left. Yeah.
Misha Makara (00:26:19.941): Right. But it moves its way into ruts, right? And so it’s only really a problem if your—if you decide to change lanes exactly right there. And, in a business context, it might be okay if you change lanes, you know, a little bit later, a little bit earlier, in order to avoid that debt. And that debt might be okay, right? The traffic is still flowing. And naturally, as you give it more time, you know, the debris moves its way off of the side of the road, right? Where it moves itself into places that are—are less offensive. Now, don’t get me wrong. That’s not an excuse. You still have to repave the road every 10 years, which I encourage every platform to do. If you don’t believe me, look at what happened when we tried to do the Vista transition, right? You had to bring people out of retirement because they didn’t know how to do TCPIP. That’s a problem. That’s a—we failed to repave the road every 10 years, just to know inventory and what was actually down there. But there is something to be said for: what is the right kind of debt? Can you get away with, you know, just paying for that free shipping, paying someone to click the button, and paying for it that way, rather than paying engineering costs versus building all of the infrastructure to support it when you don’t know if you really need...
Brian Bell (00:27:27.384): Yeah, I love that. Really good analogy. So let’s talk about Rally. What is—what is Rally?
Misha Makara (00:27:31.991): And why are you working on Rally? Yeah. So Rally is your company’s first PR hire. So Rally, what it does as a platform is, we—again, experimental design style—we absorb tons and tons of signals, and the AI actually goes and figures out its own signals: what to absorb, how to prioritize them, how to weight them. And we build a contact database of all of these different journalists, influencers, people speaking in the space. We also build graphs and knowledge maps about what are the different topics that are trending, how are they trending, where did they start from, how do they split and divide. It’s way more complicated than I realized when I started it. And then, on top of that, we have the information that comes in from one of our clients about what are they doing, what are they trying to do, what are they trying to communicate to the broader universe. And we do matchmaking. So we match the company and our client and their goals with different media influencers and what they’re doing, and we try to create press. And one of the things that was a little bit tricky for me to understand initially was PR is not marketing. This is about building relationships with media outlets to get them to talk about you and your founders and what you as...
Brian Bell (00:28:39.956): An organization are doing.
Misha Makara (00:28:41.313): So we, in order to do that, we need to make sure that we understand not just who are these media contacts and what are they writing about, but what’s interesting to them. What are the kinds of things that get traction with their audience, and what are they looking—you know, what—what’s the story? What’s going to get them? And so doing that matchmaking takes massive amounts of data. It takes a lot of iterative cycles. It varies based on the person. It varies based on the time. It varies based on what’s trending in the news. And we keep creating and experimenting over and over again. The AI just does these iterative cycles in order to figure out what’s optimal, and it keeps learning as a result. And the outcome from that is we’re able to get early and seed stage companies press, like Wall Street Journal. And it’s just unbelievably impressive. Wow. What’s happening? Yeah, yeah, that’s huge.
Brian Bell (00:29:29.103): For early stage companies. Who’s it not for? You know, when you—when you, yeah, think of some—some of the companies that have onboarded and not worked out. Yeah.
Misha Makara (00:29:36.869): So, uh, I don’t want to say it too loud right now because we’ve been very slow with letting companies in. We—we’ve had no churn, which is a whole other topic of whether or not that’s a good thing or a bad thing. The—the problem is when a company doesn’t know who they are or what they’re trying to say. And then it becomes very difficult to present them and to represent them to the world. And...
Brian Bell (00:29:55.939): In general, you just don’t even onboard those guys. So you’ve been vetting. You’ve been doing a good job of just not letting anybody like...
Misha Makara (00:30:01.962): That on the platform. Well, we’ve definitely experimented, and we’ve tried a bunch of—we have artists, we have politicians, we have seed stage companies. There’s—there’s a bunch. But it’s definitely a lot easier. And as I’m looking at the metrics and what’s getting success, I see a lot more success with the organization that know who they are and how to communicate their product than organizations that don’t. I—I can’t help you with defining and creating market fit, but if you know your market fit, it becomes a lot easier for me to articulate it, and then...
Brian Bell (00:30:33.998): To share that with others. Yeah. And I think you described a problem with the industry and PR, which—it’s very relationship heavy, and it’s kind of a slow roll, right? You know, as somebody who runs a VC firm, you know, I’ve seen this both for Team Ignite, our firm, but also for portfolio companies. This PR game can be kind of a long haul. How do you sort of measure success as you kind of onboard these companies and kind of keep them engaged and coming back month...
Misha Makara (00:30:58.121): And quarter and year after year? I mean, of course, we track the results. We’re—we’re watching. And we, when you onboard, we identify your competitors, and we ask you to verify that we got that right. And we’re looking at what your competitors are doing, and where they’re getting featured, and how they position themselves, and how they’re communicating their differentiators in relation to you. All of that baked into the Rally platform. But you’re right. It does take time. One of the advantages of working with Rally is we’re actively building those relationships, and we’re—we’re fostering them right now. Before anyone signs up, we’re building those relationships with those media, so that way, when you show up and you have a press release, we already know who to talk to, and what’s working for them, and when they open their emails, and what are the stories that are getting them views. So when you have a press release, we know better how to do that matchmaking, and how...
Brian Bell (00:31:48.356): That reporter likes to be communicated. So what’s the, you know, vision for the future? You know, five or ten years out, you guys have—you’ve been really successful with Rally. What does...
Misha Makara (00:31:57.643): That look like? Yeah. We—we do want to be every company’s first PR hire. There’s, of course, a universe where we’re working with other agencies and leveraging our data and our insights to help them be more efficient and effective, and the services that they’re delivering. Ultimately, we do want to be a relationship platform. We have this information. We know what’s working. If you’re a new journalist and you’re looking to go figure out what will people be interested in, what’s a cool story, what’s going to get me views, you can come to Rally, and we’re going to give you some interesting stories about what our founders and different companies working on. That benefits everybody: is a journalist, you get a cool new story about something that’s happening that you wouldn’t have learned about otherwise. The company is getting some press that, you know, they would like to have. So it’s a truly a win-win...
Brian Bell (00:32:41.610): For everyone involved. It’s interesting. So it’s—it’s a platform, but it’s also a—almost like a connector. But it’s also a data aggregator on both sides of this sort of kind of PR marketplace, in a way. It’s all AI powered under the hood.
Misha Makara (00:32:54.351): Yeah, um, and you might see that thread from my my past with doing digital securities and certain multiple marketplaces. But I look at it as a kind of a three-sided marketplace. You’ve got the companies and their preferences. You’ve got the journalists, the media contacts, and what they’re working on. And you’ve got what’s going on right now in the larger ethos of what the community and people are talking about. And so you have to do this three-way matchmaking, which is very—yeah, yeah. What works now is—is different...
Brian Bell (00:33:20.880): Than what will work tomorrow. Well, yeah. And you also have this—this other constituent, which you described, which is the agency, right? And I think you can get surprised by how much power agencies actually have. We did at Rocket Fuel. I was at a AI unicorn, Rocket Fuel, and we were very antagonistic towards agencies, very famously. So we called them dinosaurs, and we were going to reinvent them with AI, right? Sound familiar, right? Absolutely. And those agencies just crushed us because they had the relationships, right? And—and they—they started taking traffic and—and—and bids and ad spend away from us, especially after we IPO’d, and they noticed that these guys are, like, buying things for a dollar and reselling them for five dollars, right? They didn’t like that. Yeah.
Misha Makara (00:34:00.441): And again, remember, like, we’re doing PR, so it’s less—less about the marketing and the specific ad spend. It’s about building those relationships with those media contacts so they want to talk about you. But you’re absolutely right. It takes a long time to build those relationships. The other thing is, you know, we have advantages of technology, and I want to say a second mover advantage in the space. One of the things I said before was kind of my two kind of things I look for when I’m doing diligence on a company. Another is, everyone loves to go and talk about being a disruptive technology. And I’m sure, you know, Brian, you’ve had people go to you and say, oh yeah, we’re disruptive. All of them are, right? All of them are disruptive, right? Sure, great. Look back at the actual case study about what does it mean to be a disruptive technology. And what that means is, they usually show up to the scene, or they’re supposed to show up to the scene, and be shitty in just about every dimension except for one. They can do better in one particular dimension, and it’s usually not cost, right? So, for example, the—the classic is, when I’m—when I’m teaching this, I like to talk about addition of flash drives as a storage technology, right? We had spinning disks. All of a sudden, you had flash drives, right? At that particular moment, you had a hard drive that was a couple of gigs, and you had a USB flash drive that was—what was your first flash drive? Two megs, three megs, right? Yeah. It was terrible, and it broke. It was much more expensive in the cost per unit, but it had an advantage, which was it was a lot faster. And sure enough, as time went on, both technologies got better, right? Spinning desks became cheaper. Flash drives also became cheaper. But their advantage still stayed their advantage. They were faster in terms of random access. And sure enough, as technologies continued to evolve, the—the price point changed, and now all of a sudden had commercial viability, right? You had your exchange server, and you would all of a sudden get solid—solid state disks because your database needed to be faster. It was a lot more expensive than the spinning disks, but it was better for...
Brian Bell (00:35:54.130): That particular application. Remember, we put our app—I think it was like 2013. I was a PM at a startup, and we migrated our app to SSD on the servers. Yeah. And it just made such a difference. Such a difference. Like, yeah, but those discs were much more expensive. Yeah, yeah. It was a lot more expensive to serve the app, but, you know, the user experience—you know, speed is the feature, as Larry Page would say. It reminds me, one of the most delightful experiences I had around the same time, I think, because I had this experience at work as a PM. I did the same on my own PC, right? I upgraded it to an SSD back when it was, like, a spinny disc, right? And just that night and day difference.
Misha Makara (00:36:29.676): And I want to remind you of that point where Apple was selling you a MacBook, and you would pay more to get less storage, but it was a solid state. I don’t know if you remember that—that point. I never bought Macs, so Android PC all the way. Yeah, sure. Good for you. But—but as an example, though, right? As just a general consumer product, those were competitively viable, right? That was an interesting inflection point. So when companies come to me and they’re pitching and saying, oh, well, we’re a disruptive technology, that’s what’s going through my head, about how are you—what is your differentiator? What makes you unique and special in this domain? How are you going to continue to trend to become the new sustaining technology? And I think that that’s a very important lesson when looking at just the overall patterns about how do technologies evolve and, you know, operating in this space as a technologist. Yeah.
Brian Bell (00:37:18.037): Well, let’s wrap up with some quick rapid fire questions. You know, you’ve hired hundreds of engineers. What’s your single highest signal interview question? I actually noticed...
Misha Makara (00:37:27.483): You do it to me earlier. So usually, what I like to do is, first of all, I have to think about the role and whether or not it’s a manager or a maker role. I very much like to subscribe to the idea of service owners. So usually, when I’m brought in, I’m thinking about what’s the narrative for the company that I’m starting to set up. If we’re trying to set up for a Series A, where does that IP—and how is this going to fit in the story that I’m going to tell with the financials? So there’s—that’s a whole other other topic. But in terms of hiring a individual contributor, usually what I like to do is I go a couple levels of deep detail down and ask them to give a little bit more context or insight, especially in the kind of feeling, or, like, what was the situation there. So I’m thinking about one where I was hiring a product manager. And obviously, interviews are important, right? How are you interviewing a customer? And so you poke into that, and you’re like, well, how—how did you actually collect feedback on this thing? And, you know, they give you the textbook answer, and they’re like, no, no, no, no. How do you, like, find people? Like, how did you track your feedback, right? Those questions are a couple levels down. So if someone’s bullshitting you, you can kind of quickly see when they’re like, oh, and you see the beach ball on their—their face kind of loading and figuring it out. So I love that also because it—it shows you, and you can listen to the words that they’re using of us versus I, and you can immediately get a sense of the ownership that—that they took on through that particular point. Were they a firsthand observer, or were they the ones actually driving the process forward? So those are a couple of my favorite techniques to use.
Brian Bell (00:38:59.780): So, for startups, fractional CTO—yeah, uh, hire or don’t hire? Ooh, answer, like everything...
Misha Makara (00:39:05.582): In tech world is, it depends. It depends on what you’re doing. It’s a little bit weird on my resume because I’m always parachuted in to do something for a couple months, and my goal is to get out of there. My goal is to help the company fix it, and then to get my replacement to stop the fire and put someone else in. So again, Rally is a fun fun adventure because I finally don’t have to do that. I get to just do the thing that I enjoy doing. Fractional CTOs—definitely be very careful doing that if you’re trying to raise money, because that is an awkward place to be, and that’s been a problem that I’ve had. So come in, hey, help us raise money, and then get out, right? That’s just awkward for everyone involved, so don’t do that. If you’re—of course, if you have a CTO or you have technical leadership that leaves and you need to quickly fill that hole, right, that can be a good interim solution, especially as you’re trying to suss out what’s going on. Another important factor is just the—the network that—that person’s bringing. So especially now with AI, go figure, DevOps is kind of important, right? If you need to be able to deploy software—Rally, we deploy sometimes nine times a day. I don’t know. That’s another topic. But you need some serious infrastructure to be able to do that, and you want to be able to make sure that that deployment schedule is in alignment with the risk appetite of the company, and you have the safeguards in place in case you oops and you need to go put something back. So in terms of hiring your fractional CTO, those are the things that I would look for. But, like everything, it really depends on—on the company in this stage of maturity and what’s going on. But hiring a fractional CTO to raise money, don’t do that. Sounds like...
Brian Bell (00:40:40.996): A bad idea. What have you changed your mind on? What’s a belief that you—you held that you’ve reversed course on? This one was coming. One of the things...
Misha Makara (00:40:49.379): That I definitely kind of changed my perspective on is Web3, specifically. So I’m a fan of domain driven design, and initially, when we were doing the Web3 crypto thing, my argument was blockchain is a event sourcing and event streaming, and event sourcing and event streaming was a great pattern to use for everything across the board. And if we look at what happened in Web3, I remember the rush where everyone was trying to tokenize everything, and they wanted completely Web3—complete Web3 platforms. As you know, everything is currently running down the chain now. That’s sarcasm, right? The—the ones that were leaders were the ones that used the right technology for the job and had some kind of a hybrid. So I think I was a little bit too focused on applying it across the board. So I would have a complete Web3 event sourced application, but the cost for that—the—the business case for that kind of quickly diminishes after a certain point of functionality. So again, Pareto style: what’s the 20% that gives you the 80% of the value? What’s the part that customers are actually looking for and that they want in their—their features, versus what—what needs to be in—in that new technology? So that was, I’d say, that was one of the mistakes that I made. I was a little bit too fixated, and I want to say I drank the Kool-Aid. But I still think, through looking from a cyber security perspective, I like the idea that the event itself is an immutable thing. But there’s also right ways and wrong ways to do that, and using that as the default solution for everything everywhere is—it’s doable, but it’s also cost prohibitive, even in the—the world of AI now.
Brian Bell (00:42:26.561): Yeah. What’s the best piece of advice you ever got? If you’re...
Misha Makara (00:42:28.964): If you’re doing research, do—you can be applied or you can be pure, but make sure you articulate what it is that you’re doing and set up bounds on the experiment, because it’s very easy to keep investing and keep investing without having a defined outcome that you’re looking for from the experiment, and continuing to invest in the experiment before. So that also fits into this larger idea of, you know, learn to fail quickly. Okay, great, but at what point is a failure a failure, right? How do you—how do you set your own personal limits? You know, what are your—you know, how far are you willing to go with something before you say, all right, we’ve tried that enough? And one of my—the things that I do when managing agile teams—I love the idea of a senior developer coming, or any any developer, saying, I’d like to go try this. But then me responding back, saying, all right, you really only have Wednesday afternoon to go do this. If you can do it and it meets these requirements, then we will continue, and I’ll give you Thursday, Friday, like whatever, to continue. Or if it doesn’t, you know, hey, we tried it. We’re gonna put our lessons learned on the shelf, and, you know, we might come back to that. Or, I didn’t get to finish the experiment because of these things. Let’s extend it. So the—the lesson learned would be: make sure you have limits on your experiments. Don’t just keep going forever and ever. Otherwise, that’s how you end up working yourself into a...
Brian Bell (00:43:47.903): Well, really enjoyed the conversation. Where can people find you online...
Misha Makara (00:43:51.385): And find out more about Rally? Sure. Uh, good thing about my name is it’s very easy to find me. So, mishamakaran.com. Go figure. rally-ai.com. You know, again, come—come join us. We’re finally starting to open things up a little bit. So, you know, we have some extra capacity. I think this month we decided we’re going to allow in another five customers, and then we’re going to continue to open it up from there. But yeah, come—come join us. Awesome. Well, thanks, uh...
Brian Bell (00:44:14.279): So much, Misha. My pleasure.
