Today I’m chatting with Bob Mason, Managing Partner at Argon Ventures. Bob is a VC who seeks out early-stage founders in the ML/AI space and helps them inform their go-to-market, product, and design strategies. In this episode, Bob reveals what he looks for in early-stage data and intelligence startups who are trying to leverage ML/AI. He goes on to explain why it’s important to identify what your strengths are and what you enjoy doing so you can surround yourself with the right team. Bob also shares valuable insight into how to earn trust with potential customers as an early-stage startup, how design impacts a product’s success, and his strategy for differentiating yourself and creating a valuable product outside of the ubiquitous “platform play.” 

Highlights/ Skip to:

• Bob explains why and how Argon Ventures focuses their investments in intelligent industry companies (00:53)
• Brian and Bob discuss the importance of prioritizing go-to-market strategy over technology (03:42)
• How Bob views the career progression from data science to product management, and the ways in which his own career has paralleled that journey (07:21)
• The role customer adoption and user experience play for Bob and the companies he invests in, both pre-investment and post-investment (11:10)
• Brian and Bob discuss the design capabilities of different teams and why Bob feels it’s something leaders need to keep top of mind (15:25)
• Bob explains his recommendation to seek out quick wins for AI companies who can’t expect customers to wait for an ROI (19:09)
• The importance Bob sees in identifying early adopters during a sales cycle for early-stage startups (21:34)
• Bob describes how being customer-centric allows start-ups to build trust, garner quick wins, and inform their product strategy (23:42)
• Bob and Brian dive into Bob’s belief that solving intrinsic business problems by vertical increases a start-up’s chance of success substantially over “the platform play” (27:29)
• Bob gives insight into product trends he believes are going to be extremely impactful in the near future (29:05)

Quotes from Today’s Episode

• “In a former life, I was a software engineer, founder, and CTO myself, so I have to watch myself to not just geek out on the technology itself because the most important element when you’re determining if you want to move forward with investment or not, is this: is there a real problem here to be solved or is this technology in search of a problem?” — Bob Mason (01:51)
  
• “User-centric research is really valuable, particularly at the earliest stages. If you’re just off by a degree or two, several years down the road, that can be a really material roadblock that you hit. And so, starting off on the right foot, I think is super, super valuable.” – Bob Mason (06:12)
• “I don’t think the technical folks in an early-stage startup absolve themselves of not being really intimately involved with their go-to-market and who they’re ultimately creating value for.” – Bob Mason (07:07)
• “When we’re making an investment decision, startups don’t generally have any customers, and so we don’t necessarily use the signal of long-term customer adoption as a driver for our initial investment decision. But it’s very much top of mind after investment and as we’re trying to build and bring the first version of the product to market. Being very thoughtful and mindful of sort of customer experience and long-term adoption is absolutely critical.” – Bob Mason (11:23)
• “If you’re a scientist, the way you’re presenting both raw data and sort of summaries of data could be quite different than if you’re working with a business analyst that’s a few years out of college with a liberal arts degree. How you interpret results and then present those results, I think, is actually a very interesting design problem.” – Bob Mason (18:40)
• “I think initially, a lot of early AI startups just kind of assumed that customers would be patient and let the system run, [waiting] 3, 6, 9, 12 months [to get this] magical ROI, and that’s just not how people (buyers) operate.” – Bob Mason (21:00)
• “Re: platform plays: Obviously, you could still create a tremendous platform that’s very broad, but we think if you focus on the business problem of that particular vertical or domain, that actually creates a really powerful wedge so you can increase your value proposition. You could always increase the breadth of a platform over time. But if you’re not solving that intrinsic problem at the very beginning, you may never get the chance to survive.” – Bob Mason (28:24)

Links Referenced:

• Argon Ventures: https://argon.vc/
• LinkedIn: https://www.linkedin.com/in/robertmason/details/experience/
• Email: mailto:bob@argon.vc

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Bob Mason on the line. You’re a venture capital managing partner at Argon Ventures, specifically focused in deep tech, intelligent products, things like this. So, welcome to the show. Tell us a little about Argon and what you’re doing over there.

Bob: Thanks, Brian. It’s nice to be here this morning. Yeah, at Argon Ventures, we look to lead pre-seed rounds in deep-tech companies, typically when they’re bringing enterprise software solutions to market. So, for us, it usually means that they’re not generating any revenue, the product is incomplete, and sometimes it’s literally at company formation. So, we’d like to, kind of, be at the very earliest stages of company formation.

Brian: I’m curious, since they’re pre-revenue, when you say, “Product’s incomplete,” is this something where you’re often getting some intellectual property or a piece of—frankly, a solution in search of a problem, or you have someone that knows there’s a problem in a specific place, an actual business problem, they just haven’t finished it yet? Tell me a little bit about that, especially coming from the machine learning space. We oftentimes very technical founders can see the world in their solution, but no one else can [laugh].

Bob: Yeah [laugh]. I mean, you know, we could talk about this a little bit. You know, in a former life, I was a software engineer, founder, and CTO myself, so I have to watch myself to not just geek out on the technology itself because the most important element when you’re sort of determining if you want to move forward with investment or not, is like, is there a real problem here to be solved and not getting suckered into the notion that there’s a technology in search of a problem. Not that we’re ever perfect with that. Very much we try and ground ourselves in the vertical domain knowledge that the founder has, either from their personal experiences, research, some sort of insight over what’s going on in this market dynamic, who are the key personas that they anticipate could be buyers and users of the system, and we kind of build up from the question of why from there.

Brian: Got it. So, do you find most of the time, there’s a personal history? Like, you’re coming in with someone that had a personal history in a specific space and it’s like, “Oh, I think I can solve this thing because at my last job, we did X and—” is that—

Bob: Yeah. I would say—

Brian: —usually where it’s coming from?

Bob: I would say it’s more often than not from that. It may not literally be that they were, you know, within the industry, but they had some connection to the industry or insight. But you know, they’re also really, really clever people that fundamentally, through serendipity or not, stumble into a problem, and then they get really, really excited about it. And kind of they lend their knowledge and expertise from some other domain and kind of bring it to this problem as well. But yeah, I think there’s a prototypical founder that, like, they need to scratch that itch and they need to go solve that problem, and they have some particular insight that helps them do that.

Brian: So, just for the audience listening, part of the reason I asked you to come on the show here is we talk about this idea of product orientation for both the technology leaders that are listening to the show as well as people working in large enterprise data science teams, primarily serving internal use, but this idea of when the product literally has to make money in order to survive [laugh], like that’s the whole thing. I want to talk about that space, particularly from the lens of founders who are working with data science or they are data scientists themselves. What are those people look like? What are some of the things that—are there common things that you see need to change when we’re talking about these technologies in terms of the people or the mindset or I can think of some of these myself just in terms of there tends to be a little bit more introversion there, less interested in going out and talking to people, things that are very antithetical, I think, to doing great product work. I’m curious if you see patterns here with the founders that come in your door and habits they have to unlearn or new skills that they particularly have to learn because they are smart, they do have the technical knowledge, all that stuff in spades, I’m sure. Tell me a little bit about, like, the people coming in the door. Are there things that you’re like, “All right, we got to run you down the plan here?” [laugh] like—

Bob: [laugh]. Being a former CTO, it sometimes pains me to say this to the technical founders of startups, but at the end of the day of the actual technology, it doesn’t really matter. Obviously, it has to work and it has—and sometimes there’s, like, a technical advantage that you’re sort of building in to build long-term differentiation, but ultimately, it’s really about kind of the sales and marketing strategy because you need to be able to sort of feed the engine and really justify the value creation that the technology brings to bear. Oftentimes, it’s really easy to have an in-depth conversation around sort of the market forces or the dynamics of what’s happening within a particular industry and their approach to using data or, you know, sort of machine learning or what have you to go solve that problem, but then they haven’t spent enough rigorous time thinking about okay, well, how do we actually bring this to market? Who are the buyers? What is the sales cycle like?

And obviously, at the early stage, you don’t know the answers those questions, but oftentimes there’s a lot of research or at least hypothesis testing that you can do to kind of validate that. The NSF has a really interesting educational program called I-Corps, and one of the fundamental tenants is that you should go speak to a hundred people. And I think that type of user-centric research is really valuable, particularly at the earliest stages, when if you’re just off by a degree or two, several years down the road, that can be a really material roadblock that you hit. And so, starting off on the right foot, I think is super, super valuable.

Brian: Is there a reluctance to do that kind of work a lot of the time?

Bob: I don’t think so. I think it’s just, like you said, it’s not to say natural to everyone. The best opportunities I see is a really balanced team, right? So, you have the prototypical business leader and the prototypical technical or product leader and they come together with a shared passion and they bounce off of each other. But oftentimes, I see the product and technical people because of the underlying understanding of the data or the technology itself, they actually may have greater insight sometimes on, you know, how to drive a go-to-market or who the right buyers are, or what have you.

So, I don’t think the technical folks in an early-stage startup absolve themselves of not being really intimately involved with and think strategically about their go-to-market and who ultimately they’re creating value for.

Brian: You might be biased just from the subset of people that are coming to you and they’re willing to, like, go scratch the itch that you talked, but do you think there’s anything inherently difficult about someone that comes from a data science background moving into a product leadership type of role? Is there any reason why they may], “Well, it’s an uphill battle, and it’s going to be really tough,” or, “Nope, they actually make great ones?” Any comments about that? I’ve heard, “They don’t make really good—in general, you really need to hire some other people like that.” There’s definitely some voices in the data space that believe that, especially about the transformation enterprises are trying to have an adopting more of these digital-native product orientations with the work that they’re doing. I don’t necessarily feel that way, but I’m curious what your take is.

Bob: My personal background and journey came from being a software engineer, software architect, evolving into be a CTO, and in my role as a CTO as effectively a Chief Product Officer, so I grew in my own career of really kind of understanding the power and the opportunity to be very engaged with customers and really understand their problems and internalize them and did kind of use that to drive a product roadmap. I don’t see anything inherent within fields of data science or software or machine learning that would prohibit someone from doing that. Obviously, it’s a personality choice. Do you find joy in engaging with customers and kind of learning with them? And if you don’t, that’s fine.

You know, that just may not be what your power alley is, but once again, that may mean that you need to complement yourself with someone that does find joy in that regard. When I first engage with technical founders, often are having a conversation with them over time, a kind of pow—where they see their own role evolving, and I see, oftentimes, there’s sort of three personas of a technical leader that often are exhibited by a single person at the very beginning, but over time, they want to become more and more specialized. So, you have someone that is a purely technical innovator, they’re on sort of the cutting edge of the science of whatever they’re building, a distributed system, machine learning, data science, algorithm development, what have you. There could be someone that is sort of a head of engineering and they find joy in building great teams, improving team velocity. And then you have may have someone that has a strict product vision: where is the world going to, what is the needs of the business?

Someone can try and embody all three, but it may actually be that you’re only good at scale, or you only find joy out of one or two of them, right? And so, if you start thinking about and being retrospective about where you want to spend your time, you can start thinking about who you want to complement around you to kind of fill those other gaps.

Brian: In terms of the—when we talk about the part where the tech is actually supposed to get out there and start doing its magic, one of the challenges I know a lot of teams have in this space is low adoption. So, either they get the foot in the door on the technology—so this is from the technology industry side—they sometimes get the product in there, but the dirty truth is that a lot of those seat licenses aren’t getting used. And then renewals come up and then [laugh] it’s like everyone’s nervous, right, because the stuff’s not getting used. Similarly, on the enterprise side, it’s just giving people what they asked for a lot of the time, not digging into what’s actually needed, and then oh, this dashboard doesn’t get used, or this new tool we built didn’t go through change management, didn’t—there was no operationalization plan for it. It was never designed, it was just built as a little island of tech.

So, I’m curious if this idea of, like, long-term penetration, which is, like, getting past the first sale, but actually, like, did you build something that’s what I call indispensable, right, now we can’t live without this thing that pulling it out would be really disruptive. Or it just makes my life so much better that I don’t want to not have it as part of my toolset or whatever I’m doing. Is that something you have to think about at all with the companies that come in? Are you thinking past that initial sale? Are you really there to kind of help them get to that first… win? I’m just curious how much you think about the low adoption thing or if that’s on your radar at all.

Bob: It’s certainly it’s something to be mindful of. Obviously, when we’re making an investment decision, they don’t generally have any customers, maybe there’s a early pilot in place, and so we don’t necessarily use the signal of long-term customer adoption as a driver for our initial investment decision. But it’s very much top of mind after investment and as we’re trying to build and bring the first version of the product to market. Being very thoughtful and mindful of sort of customer experience and long-term adoption is absolutely critical.

Grossly speaking, there’s probably sort of two vectors that you really have to pull across. So, one is, like, are you actually building something that the customer needs? And oftentimes you may have a hypothesis and you kind of go build that with as much information as possible and you’re just wrong. And sort of being retrospective in that process and realizing that you have to pull back or go in a different direction. But sometimes it just requires customer education, planned approach of managing expectations and getting sort of buy-in and really having a customer success plan in place when the product is actually delivered to them.

So, I think it’s really valuable to sort of being pragmatic and being open-minded, that perhaps what you’ve built as missed the mark a little bit, but actually investing the time and energy with your customers and making sure that they’re well educated, that there’s ways that they can provide you the right feedback, that you’ve pilots [unintelligible 00:12:54] defined mutual success criteria, I think those are really important aspects to really validate if the value that you’ve created in the product is being realized.

Brian: So, you mentioned this customer experience thing and I remember reading in your bio when I was preparing for the interview, you mentioned suddenly, having an opinion about design and user experience and product and all of this, I’m curious, how much does user experience matter in the context of these products?

Bob: For most of the companies we invest in, I think the user experience is pretty critical. Like, obviously there are, if you’re designing a database or you’re doing some sort of, you know, networking technology, maybe there’s minimal touch points to the actual end-user, but even from that perspective, if you think about sort of developer experience as a form of user experience or customer experience, I think that is as equally valuable and important as having a beautiful UI. I think a lot of my personal inclination around sort of design and user-centric actually comes from some of my very first work experiences, actually, which were in desktop publishing and graphic design when I was first in middle school. And then in high school, I was kind of designing logos and putting pamphlets together. And didn’t really realize it at the time, but I had to kind of think about who’s reading this. How’s the information being presented? What choices am I making in font and graphics?

And I think that sort of early nascent experience sort of I kept building upon over time. And my first job out of college actually was at a startup called Art Technology Group, this really interesting blend of being very design-centric. And I think we had out of a group of ten of us, there were probably three or four designers at that stage where we were sort of thinking about design as a wholly integrated part of the engineering process. And so, I think I was apprenticed well in that. And that sort of has permeated my life.

And later on when we sort of—I was a software architect building enterprise software, we thought very deeply about the developer experience and wanting the developers to have a fun time with our products. And having really well-thought-out documentation and well-thought-out API endpoints and reference applications and open-source code and the like. It’s always kind of thinking about who is the end-user and being empathetic to their needs is really critical.

Brian: When you get pitched or when teams come in the door, have they typically gone through any type of formal design in the work they’ve done up to the point they’re coming to you, or is that usually an afterthought? I’m curious about how mature it is when it comes in the door.

Bob: I would say there’s some teams that have a more natural inclination to be sort of design-centric, or they recognize the value that they want to place in design as a way to sort of create differentiation, even if they don’t necessarily have the resources to do it at the beginning. And it may be that just the founders themselves take their best shot. And you know—but the conversations we can have about, well, who are your personas? What is the ideal customer persona? Who are your buyers? What are the problems are they solving? Why did you make these decisions? Like, you can kind of get a glimpse and into their sort of user-centricity, which I think is really exciting.

Brian: I don’t know if you get into much kind of the difference between buyers and users and do the teams understand the difference there are sometimes about who’s actually writing the check versus who’s going to use it? And then that’s sometimes where the adoption thing tanks, right, because the team that’s using it, it’s not solving their need, but the promise sounded really great. And everyone could imagine the promise of the product because, “Oh God, this tool will cut our call center cost by X because of Y and Z,” but the call center people don’t want to do it that way.

Bob: As an engineer and product leader, I’ve fallen into that trap myself. So, [laugh] you know, it’s something you’re always mindful of. And I think, where we try and be helpful to a team, or particularly if they have an enterprise software solution, like, it’s often a very complicated buying cycle and there are multiple stakeholders, there multiple layers of authority sometimes, and sometimes you have to drive consensus before you can kind of move forward. Being mindful of who are the users using the software, I think is top-of-mind. And so, we just try and educate you know, founders about that dynamic because it may not necessarily something be obvious at the beginning, particularly if you’re a first-time founder. You know, you may not necessarily realize what a complicated world business-to-business software and enterprise solutions can actually be.

Brian: Do you see any differences in terms of how the product needs to be designed, or what the experience needs to be because of the technology that’s being used? Because we’re dealing with probabilities with predictive technologies, for example, it’s not binary, it’s not like, if you do this, you’re going to get this result every single time; it’s never going to be different. Now, all of the sudden, it’s not. Or it’s disruptive because the model doesn’t say always say how it came up with thing—it doesn’t say how it came up with the prediction and so there’s some opacity there, it’s a little bit opaque, perhaps. Is there anything different about that you see in terms that teams need to think about when designing?

Bob: To be honest, we haven’t really talked about in that context. Oftentimes, there’s certainly a data visualization problem, there’s sort of a language of how you want to represent numbers and statistics and probabilities, to be able to do that in a manner where an average user kind of gets value out of the data. Because you know, if you’re a scientist, the way you’re presenting both raw data and sort of summaries of data could be quite different than if you’re working with a business analyst that’s a few years out of college with a liberal arts degree. How you interpret results and then present those results, I think, is actually a very interesting design problem. That’s probably one of the critical components of how you actually sort of create value out of the software in sort of the data science and machine learning realm.

Brian: When you worked in your tech background, et cetera, other maybe they’re not design specific considerations, but in terms of the product, the inherent nature of using deep technology or machine learning or AIs, is there anything different on, maybe, the business side, if it’s not the design side that founders need to be aware of when they’re trying to leverage these technologies? Like, oh, the onboarding period is so much harder, or getting buy-in is tougher because of X, like, any patterns that they have to start watching out for?

Bob: Well, I think oftentimes, AI-based solutions—or sort of data-centric solutions—can have a cold-start problem where either the model that’s being delivered to the customer or the refinement of the system requires sort of unique datasets and those datasets actually come from the customer. And therefore, there’s a challenge that the potential customers may not see immediate value unless you kind of go through this training process. And that could require just crunching raw data, it could require a human-in-the-loop process, but I think that challenge needs to be sort of faced head-on and you needed to be able to through to think about how you can create value through your software system pretty immediately, despite that problem. So, sometimes there are some relatively quick and easy wins that don’t require a lot of deep technology machine learning, you know, sort of vast troves of data analysis.

It may be really beneficial to kind of get your foot in the door by solving some really simple problems that may have to do more with process or workflow or some sort of other technical integration, and then over time, you create more and more differentiated value because, you know, the data sort of creates a positive feedback cycle into the system. But I think initially, a lot of early AI startups just kind of assumed that customers would be patient [laugh] and would let the system run or they would invest the time or energy, and then you know, 3, 6, 9, 12 months later, like, there’d be this magical ROI, and that’s just not how is this people operate. They need to—you need to really have a visceral feeling of value-creation in a relatively short period of time. Sometimes it’s the order of minutes or hours, and not just days or weeks.

Brian: I don’t know how enterprise cybersecurity software is sold, but it’s like, I wonder if it’s mostly after there’s a disaster because it’s like, you don’t really feel that pain ever; it’s just paying for insurance, you know? It’s not a bleeding problem. It’s just, like, cost of doing business, but it’s never bleeding and it feels like it would be a tough sale, you know, when it’s taking that long before you ever see the value until you find out what you’re protecting, right, or you have some idea. “Oh, look at all the stuff we stopped, the opportunity stopped,” you know?

Bob: Yeah. But obviously, like, if you take the notion of crossing the chasm, the first step of any startup is to find those early adopters, you know? And those early adopters have the foresight, they have the risk-taking gene built into their DNA, even if they’re at a Fortune 500 company, right? Like there’s something about how they want to build their career and how they want to differentiate their own leadership that allows them to kind of take the risk on an early-stage startup. And ultimately, oftentimes, what you’re really trying to do in your sort of sales cycle, is to identify as quickly as possible, to triage those people, and to realize there are a whole bunch of people that may be theoretically great business clients, but they’re not early adopters and it doesn’t matter how much time or energy you spend with them, the organizational structure or the inertia and their own risk proclivity won’t allow them to get over the finish line and so you just need to park them and keep them warm for another year or two, while you prove out and go actually demonstrate value with the leaders that are going to be early adopters.

Brian: And then come back with a higher price.

Bob: Exactly [laugh].

Brian: [crosstalk 00:23:14] [laugh] because you didn’t buy [laugh]. I want to rewind a second when you talked about showing some quick wins or getting some value on the board early. That sounds a lot, if I was putting my listener hat on, I was like, that sounds a lot like going in and doing consulting, where it’s like, “Oh, well we’re trying to sell you X this hammer that we made, but you—oh, you kind of need a screwdriver. Or you need plumbing, you don’t need a hammer, you need plumbing.” That sounded like services work.

So, were you—telling me about how do you go in and show quick wins with a product that does—it’s fairly narrow in its scope of what it does, but then you’re saying show some quick wins? Can you talk about that? Or do you mean the whole product needs to just be focused on quick wins initially?

Bob: Yeah, I was thinking about this dichotomy, let’s say between deterministic engineered software, you know, that really is around workflow enhancements, versus, you know, some sort of predictive model that is derived off of your training datasets and the like. Oftentimes, the sort of exciting part of the technology realm is on the bleeding edge of a building some new model, but the reality is, there may be an easy fix to a problem within their overall company workflow or engagement with their own customers that doesn’t require any advanced machine learning. Not ignoring those facts—and once again, if you’re really customer-centric, you may realize oh, we could actually solve this really interesting, small problem first and it allows us to build a trusted relationship with the customer. And then over time, with that trusted relationship, we can get access to data, they’ll actually spend the time of using our system which helps train the system. So, that’s what I was thinking.

To your other point on kind of the role of services, particularly in enterprise software, I do think there is a valuable strategy that can be pursued. In both my previous company ATG and Brightcove, ultimately, we became sort of global public enterprise software companies, but at the very, very beginning, we were kind of, more or less, like professional services consulting shops where, you know, we had a core hypothesis, let’s say in my last startup, Brightcove Online Video, that video would be as ubiquitous as [unintelligible 00:25:32] on the web and you need new cloud-based platforms to allow corporations to kind of manage the publish and distribute video online to their customers. At the very beginning, we didn’t have a full end-to-end solution designed or built, but we definitely wanted to engage with customers in market. So, when we first would pitch a solution, not a product, like, a comprehensive solution to the customer, maybe 25% of that solution was actually, like, reusable code that was like platform-centric that we could use to the next project and we just built a lot of custom stuff on top of it. Sometimes it was a very natural demarcation.

So, in the online video space, oftentimes, we build custom video experiences a hundred percent, you know, specialized code just for that client, but the back-end from a content management and workflow management was repeatable, reusable, and there were good API endpoints between the two. But then over time, we could actually build reusable video experience software that reduce the level of complexity or customization over time. But we didn’t have to do that from day one. We could augment our core platforms through services and custom engineering. And you just have to be mindful of that as a strategy that you’re imposing and not kind of getting stuck of just being a consulting company.

Brian: One of the challenges I think, with platforms is it’s the promise of the world of all the things that it could do, but sometimes the instantiations themselves are missing or the people that are supposed to use it aren’t seeing the value there even though theoretically this platform is supposed to support all these different use cases. My general thing is, you may need to design something on top of the platform that’s end-to-end for someone to actually first see the value of it before you can start, let’s move it to this industry. Let’s move into this industry, let’s move into this industry, or to different verticals. And I’m curious, do you get a lot of platform plays coming in the door, where it takes crossing the chasm a bit for someone to see what the potential is there? Or, talk a little bit about platform products versus actually end-to-end solutions there.

Bob: Part of our hypothesis of our fund, and our thesis, is that we’re actually sort of entering a new business cycle where capabilities should be more vertically-oriented, they should be more domain-specific, they should be more of a, what I would roughly call, like, a business application in its style, versus a very broad horizontal platform. Part of that is just the there’s enough time that has gone through, enough domain experts are comfortable with the broad outlines of cloud computing and data and machine learning that they are now having intrinsic insights into how to apply those technologies to actually solving very specific problems. Obviously, you could still create a tremendous platform that’s very broad and horizontal, but we actually think if you focus on the business problem of that particular vertical or domain, that actually creates a really powerful wedge and you can increase your value proposition, you could the platform term, increase the breadth of a platform over time. But if you’re not solving that intrinsic problem at the very beginning, you may never get the chance to survive.

Brian: Any other kind of future thoughts about where things are going? So, you’re saying vertical focus, a little bit more domain specialization, less broad horizontal, you could solve the world of problems, you know, across all these different industries with this platform. Any other trajectories that you’re kind of seeing, especially with machine learning and analytics space, data science, et cetera, with tools using these technologies, where the market’s going or resistances that are going to come up, or opportunities, anything like that?

Bob: The cross-collaboration across domains is really, really interesting. Just as a small example, our most recent investment is in a company called Trilobio, which is building a robotic lab automation system, so for synthetic biology and molecular labs. The three founders blend both robotics, computational biology, and sort of pure scientific biology as skill sets. The teams that they’ve had to assemble include machine-learning engineers, mechatronic engineers, and pure software developers. And for them to bring their solution to market, they really have to integrate these disciplines.

They’re using machine learning integrated within robotics to be able to do, like, path planning for their devices. They’re designing an entirely new open-source programming language to control these robots. They have to be thinking about their end-users who are biologists that have never written code. And so, what type of packaging system can they put on top of it to design protocols that get loaded into an app store, for example? That’s actually going to be probably one of the most interesting and powerful secular trends, a cross-disciplinary integration of a lot of different skill sets.

Data scientists and machine-learning engineers can be really a key pillar of that, but they should be looking for, you know, problems and domains from friends and ex-colleagues or other serendipitous connections and merge their perspective with theirs as well.

Brian: That sounds like an exciting design space, too, to work on. Thanks for sharing those insights. Any closing words, just for our listeners that you’d like to share? It’s been really great to have you on Bob, any final thoughts?

Bob: You know, for us as a fund, it’s never too early to reach out or to see how we can be helpful. Oftentimes because myself and my partner, we’re operators and entrepreneurs at heart, we like to play in the mud and help people figure out, like, well, what are you actually building? And why are you building it? And here’s some ideas and thoughts from our own personal experiences of building startups that may be helpful. And so, I would just encourage people, if they have the inclination for a bit of risk-taking, particularly if they’re early in their career, kind of think about either joining an early-stage startup or, you know, being part of the entrepreneurial community and launching some endeavor on your own. It’s not easy. When you think about probabilities and math, you will most likely fail [laugh]—

Brian: [laugh].

Bob: But if you can have an impact in the world, it can be some of the greatest fun and joy through the pain.

Brian: Is argon.vc, is that the best place to get in touch with you, or LinkedIn? Where do you kind of hang out if people want to reach out?

Bob: Yeah, LinkedIn is good. Our website is argon.vc. You can email me bob@argon.vc as well. I really appreciate the time, Brian.

Brian: Yeah. It’s been great to talk to you. Thank you so much for coming on Experiencing Data.