What I learned from building, and exiting a startup — Kirsten Mann (Strategic Advisor)

0:00Randy Silver: Is it a goal of yours to make more money in 2026? My name is Travis Chappell and I'm the host of the Travis Makes Money podcast. It's the only podcast on Spotify that brings you two episodes every single day on how to make more money. From side hustlers to real estate investors, brick and mortar owners to online creators, beginners to billionaires, every conversation will give you the ideas, inspiration and practical tools you need to make more money and earn your dream life today. Subscribe right now to the Travis Makes Money podcast on Spotify and I'll catch you over there.

0:32How do you rebuild after a setback? Find your next direction? Or understand someone whose life looks nothing like yours? On Let's Have This Conversation, journalist and motivational speaker Kevin McShan meets the people behind those questions. From resilience and well-being to careers, leadership, and human connection, discover personal stories and expert perspectives that could change how you see your own life. There's a lot we can learn from each other. Let's have this conversation.

1:04Randy Silver: Search for Let's Have This Conversation wherever you listen to podcasts or click the link in the show notes.

1:21I think what people get caught up with building, and I'm seeing this time and time again, is distribution is the product problem right now. People get so caught up in the build and is the product desirable, usable, all of that stuff? Not can we get it to people.

1:46Randy Silver: kirsten this is your third time back on the podcast we asked you to come back on uh in fact you you told us you had to come back on and we agreed because last time we talked to you you were building up your new business uh visory and now you are no longer building that business and you wanted to give us a bit of a retro and a look back at what happened so so what happened well i think it's it's one of those things right that you and it's always when you do the retrospective i think that's where the powerful lessons and learnings come through so i've actually documented a lot of these and there and i put them on my site um under visory.co so if anybody's listening to this and they're thinking i want to read more about this it's all there but really as you know randy i think i never really set out to be a founder like i've worked in um for about over 30 years in product and worked alongside hugely successful founders.

2:41And I knew it isn't a role that you want to walk lightly into because you need this problem that you care enough about to live with 24-7 because you never end up switching off. And so I went in with my eyes wide open and I knew the challenges with things like pricing and distribution. And I wanted to treat advisory like any other bet with stopping conditions built in from day one. So my product instincts transferred fine. What I think I underestimated was wasn't the technical side, it was the human side. And we had AI agents doing a lot of the building. For just context, it was a board software app that we were building, which used AI to analyze board packs.

3:25So I should give that context. And it was just the two of us, Toby, my co-founder and myself. and because AI lets you move so fast, we felt the pace was just pointless. And so it's brilliant for getting to market really quickly. It's also hard because suddenly you're doing all the go-to market work at the same time as building. There's really nowhere to hide and pause. So suddenly I found myself being CEO, the PM, the UXer, the researcher, the marketer, customer success all at once. And what's different now is that I think I understand the tech from the inside, not just orchestrating it as a product leader.

4:05And I'm probably more sharper on the commercial questions as well, but we can go into some of those things. And I think that that's really helping in my advisory work now.

4:15Randy Silver: Well, let's continue to set the context for this. So you started advisory, that you and Toby, you built it up, you went to market. Let's just do the two-minute version. So what happened? You're no longer involved in Visory Day today. Did you shut down? Were you acquired? Did you IPO? What happened? We've exited and realized pretty early that the channel, we couldn't own the channel, and that was a key part of what we were testing right from the outset. and I think it's one of those things that you go through and you know I was a board director obviously and I'm building a product for board directors and so suddenly you're the buyer but that is a that is dangerous as well and I want to talk a bit about why that is and what the advantages were what the problem was that I was living there but the advisory the product will live on under another name.

5:13And so now I'm doing advising work under my Visory brand.

5:19Randy Silver: So this leads to an interesting thing because you're building up a product when you were starting this and then you sell it into a bigger package. Looking back on it, was Visory a product or was it a feature of something else? I think this is going to happen increasingly a lot for people, but something that we would have thought as a standalone product. Now the defensible mode around copying or building things is, is, you know, so much lower or so much harder to defend. Yeah. Do you think that this was a feature or a product or, and is that going to continue to be a problem for people? Look, I think it's a really good point.

6:01It's for advisory. It is a product still and it's but it's in an ecosystem and of jobs to be done around boards and um so if part of that ecosystem for example is another ai product that creates the board pack and lindvisory is the product that analyzes the board pack but there's other ones there that do the effectiveness of the board itself so you could say are they features i i don't think it's they're contained offerings in their own right that are giving value. I mean, we define product as something that supports people in a process and provides value. And so I think Visory did that in its own right.

6:46But you're entirely right. I see some things and I think that's kind of just a feature that would need to be with something else for it to be totally valuable. For us, the Visory concept was valuable in its own right. We just went down the path we did because was we wouldn't have been able to get access to the user easily that needed that product. So we can kind of talk through what led to that decision as well.

7:12Randy Silver: I totally agree with you about that. But I think one of the key things of making a product standalone and work is it's feasible, it's usable, it's desirable, but it's also viable. And it sounds like the viability was the issue for you. Yeah, it was viral in the sense of people were paying for it. And the commercials were fine at a certain point. But what started happening was I wanted this to be a B2B sale. So basically the people using it were the directors and they would be the people buying it directly. And that started off fine and that was the way that it was working. but pretty quickly it flipped to an enterprise sale.

7:58And that was because it was a different type of success. Like other people started talking about it on the boards and say, hey, can we get access to that as well? And then the minute you're dealing with a chair, a co-sec who say, oh, yeah, we'd like to buy this but we want a deal across five people. And, oh, by the way, you need to go through our IT person or our AI transformation person or whoever it was, or our legal person, suddenly you're in an enterprise sale. So it wasn't a direct-to-director slash B2C sale anymore. And for me, that was something right from the outset I was testing to see whether this could be.

8:40When I could see it wasn't going to be that and it needed an enterprise backing behind it, that wasn't what I wanted to be doing.

8:48Randy Silver: Okay, so it's not that you couldn't, It's just that it wasn't the vision that you had for where you wanted to go. It wasn't the company you wanted to be running. Exactly. And also building that up and building the channel behind it takes a lot of time. And I've lived through that in a number of enterprise companies now. So for me, it was like, where are AI's moving, the speed, all the rest of that? You have a choice. You can build it all yourself and try and create the channel. and then, you know, raise money, do all the marketing, all the rest of it, or you can find an existing channel. And that's what I do.

9:25Okay.

9:25Randy Silver: Let's talk about one of the other challenges or lessons learned from this, which is something I'm seeing increasingly. It's something I see with Faith Forrester, who I'm doing a separate program with and doing some, and a lot of people that I know who have said, oh, this is really interesting. I have tools now that allow me to build fast or prototype quickly at the very least. And maybe I can take it into production. And I have a problem that's been bugging me. Maybe I can solve this and turn it into something that's a sellable product. I can turn it into a business. But we used to fall in love with a problem, as you said, that you get obsessed with.

10:04Randy Silver: But it was somebody else's problem that we wanted to solve for them. Now we're trying to solve our problems. What was that like for you? You're a board member, a board advisor. and you were trying to build, you were building a business to solve your problem. Yeah, I think being your own customer is the best focus group you'll ever have and the most dangerous. And so the advantage is real because in my case, I'd live the problem. You know, I've had the situation where it's a Friday evening, I've got to pack a board pack that I've got to read and that can be a hundred or 500 pages. If you're on a listed board, by the way, that can be a thousand or two thousand pages and you've got the weekend to get across it and you read along and you're kind of feeling like you've seen 80 percent of it before and you're knowing there's something in there that should probably be keeping us up as directors at night and I didn't need to research that to feel that right so that's the exact track because demand isn't me wanting to thing I'm building, real demand is someone trying to make progress and blocked by the options that they've got.

11:12So my own conviction was the least reliable signal in the room. And I kept having to go back to the jobs to be done, not the features. And so I could see this is the mistake that people making. They're getting so caught up and we can do this, we can do this with AA, look what I've done in half an hour. It's amazing. But this was so critical from my point of view, because the example that comes to mind with what we were doing was the synthesis produced by AI was quite generic, for example, initially. And when we were getting feedback from directors and things, they were looking at that. And they said, one director said to me, you know, don't build a tool that flattens everyone's the same, summary and the same questions.

11:57What I bring to this board is unique. So make the insight reflect that and how I think. And that became a design principle for us. But it's one of those things where it was an example for me where I treated myself as one data point and kept testing against people who weren't me. And I think it's so critical for the people building with AI to do that. And I think we're going to have a bit of a chat about, you know, we used to speak about the MUN test. It's gone from the MUN test to the ME test now, I think. So that's something that's really fascinating to me as well.

12:32Randy Silver: I mean, I think the me test was always something that was useful. This is, you know, we didn't want to show something to customers or potential customers until we thought it was potentially viable at least. So we always had a bit of a me test. I think the problem that you're referring to is when the me test is the only test that you're doing. Well, it's kind of, I mean, you would have encountered this already. Like how many people have you spoken to where they're suddenly saying, oh, I vibe coded this thing over the weekend, right? And they're building it for an audience of one, which is themselves, and mistaking it in some ways for validation that this solves my problem.

13:11And so building fast and cheap for yourself. And as you said earlier, you've proven maybe feasibility and usability for exactly one person, being you. but you've done nothing to validate viability or desirability for anyone else which is perfect right up until you decide to have a business and then that's the time where you have to assume you're not the 10 and possibly not even the ICP and your real ICP is whoever rips this thing out of your hands and closes this deal fast and stays happy afterwards. So assumptions are own comfortable truth sometimes, which is exactly why people skip this thinking and get caught up in the vibe coding and testing because it's so immediate and you can see that.

13:59But I would say to anybody vibe coding something brilliant this weekend, whether it's any good is never really the question. The question is whether anyone who isn't you will pull this thing out of your hands to get to it.

14:12Randy Silver: You've already mentioned a couple of people that you've talked to that gave you really strong feedback along the way. But getting access to board directors is your target market in this case. It's not always the easiest thing. There's not people who are incredibly rich on time in many cases or always very generous with time. It's a lot easier if you're in the population, I'm assuming, than just trying to get access to that population. But I know lots of people who have trouble getting access to their target customers on a regular basis. And it's not as bad as it was a few months ago, but I used to get solicitations every week for doing discovery with synthetic users.

14:53Randy Silver: So what do you think the right balance is there between, so you've got the me test, you've got the actual test of talking to real people, and then you've got something in between of we've coded up a bunch of agents to pretend to be these people. What was your experience or what's your opinion on that approach? Yeah, it's a really interesting one, right? I suppose part of it, I think those kinds of things are good first validation steps sometimes depending what they've been trained on as well. So if these agents have been trained and like you've done a lot of discovery interviews and things on your potential users and you've got those interviews and you've then used them to train those agents so they've got a base level, then it's a nice, quick, early validation part.

15:45But of course, nothing can beat a real person who's talking about the reality of what they're dealing with. And also, I think there's another aspect to this, Randy, that a lot of people overlook. It's because it's a lot of when you're doing those things with agents and things, it's about usability testing and it's not really getting into the heavy viability stuff. And for me, a lot of people, when they're talking about taking a product to market or at least testing it, they think of stripping out friction to prove demand, getting users and people using it as fast as possible. And I think that's actually backwards.

16:26at least when you're testing an idea, because pain is not the same as demand. You know, life is full of on your, not on fire moments. And we do absolutely nothing about it, right? So the only real test is what have you actually done about it? And when you're talking to somebody, the honest answer is nothing. There's no force there. So that was something I was testing to fail, not to pass. Now, most people, especially with these agents environments, are running tests to confirm they're right and not to find a reason to stop. So that is so critical. And an agent's not going to think through these things that we're talking about now with demand because you're not pushing them down those kind of scenarios and they haven't necessarily got the context to think in that way as well.

17:17so this pull is really critical and I'd love to kind of talk through a bit of an example how I tested that because I think this is one of those really interesting areas

17:29Randy Silver: yeah I would love to hear more about this because you hear uh this kind of thing all the time we we go back to the scientific method and people think it's proving that you're correct and really what you're trying to do all the time is prove that you're not correct uh if we go back to that So we're waiting for the stop. So, and so this was, for me, this was right in the stage before I actually decided to build anything because I actually had the product in a form that I developed while I was at Prospection, which was an AI first company. And the guys had helped me set some things up there so I could run an LLM across my own board packs and things.

18:08Now, and people had heard about that and was kind of wanting me to productize it. But before I built anything anyone else could touch, I was talking to a lot of directors and, you know, and we'd have these conversations over coffee and things and they would be, oh, this would be amazing if I could have access to this. Of course, because everybody has this problem where they're drowning in these board packs and they've got to get the key insights and be able to come into the board meeting and have all their questions really sharp because you don't get to ask all the things that you want. So you've got to almost kind of prioritize that as well.

18:44But so what I did before I built anything else, I basically said to the people I was speaking to, I want two board packs and I want an audio recording of you reviewing yourself reading a board pack. And then I'm going to be able to see whether what I can do with the product is better than what you can do on your own. And that's hard, right? Like that wasn't an easy ask. because you're dealing with a board pack is one of the most sensitive documents a company has. So highly confidential material. And hold on, you're going to, so I'm going to have to ask permission to give somebody else these board packs.

19:25And then I'm going to have to read aloud how I interpret this board pack and record it and give you that as well. They're hurdles. and for me it was important it's a big ask but it also told me whether there was enough pull there that people really had this problem that they were willing to go through that pain to get a solution so you know the talk over coffee is cheap getting clearance to hand over two board packs and do that audio is expensive. And that was, for me, was showing me force, not sentiment. So I wasn't interested in nice words. This is impressive. You know, all of that type. They're polite nose.

20:10I needed to hear people say, I'm going to do this because I need this now. That's the real thing for me. We're the real signals.

20:19Randy Silver: Is this something that's specific to the work that you were doing or is this more universal in that? I think it's universal. But when you're dealing with board directors, what you're paying them for, the value being given, is their insight. And insight isn't something you get from just glancing at something. It's doing the hard work of the interrogation. The friction is the critical thing. something that might make you go a little bit faster that might help you collate your thoughts and test your your thinking and things like that i can see that being really valuable but i don't want something that summarizes it all for me and does my job and potentially replaces me uh as as a board director then what value am i adding but there are other things where where efficiency is the goal so is it in a different type of product setting where efficiency is purely the goal do you think friction is also useful in that case?

21:12So if somebody will jump over hurdles to do things that then let them use your product, that's a pretty good signal that you're onto something. So that is where I'd be doing that friction things up front when you're testing these concepts. As you get into creating the product and stuff, reduce the friction and let them get as efficient as possible.

21:36Randy Silver: I've also heard people talk about the, you know, once you've done a test or a pilot and saying, now, what would you do if I took this away from you? And seeing, you know, that's the opposite way of doing the validating demand through some friction. Well, I wanted that test because I didn't want to build anything. Nobody was going to jump over those hurdles in the first place, right? So for me, if they were even going to do that at the start. That was what I needed enough people to do that. And I said, if I can get 10 people who are willing to do this, I'll go ahead and start creating the product.

22:12I got 10 people who were willing to do it. But pretty quickly then I moved into, okay, I want these people to actually pay for this though. What do I have to do to make sure that people are paying and seeing there's enough value here? And how do I get to that point as quickly as possible?

22:30Randy Silver: And once you've gotten to that, or once you pass the point where you validated that there is demand and you want to do something, you start building. And one of the things you discovered in this is that you built something that people said they wanted, but they didn't actually use it, which I think we've all been there. But most of us, we've all been there. Not everyone knows that they've been there, but not everyone has wired up the metrics very well. But what was that like? How do you deal with that? I'll tell you what, like, again, you know, we all should know better. And look, there was this feature called cross-pack search, and it's my favourite example because it really lured me as well.

23:14Now, in research, it drew the strongest reaction of anything that we showed people. So every director described the same thing or the same needs. They basically wanted to find an issue across multiple packs, which they only had a vague memory to go on. I'm sure they talked about this three or four board meetings ago and where was that? And so it was kind of vague. And it came up so consistently, right? And Toby and I, when we were prioritizing what we were going to do and which jobs we were going to service first, we kind of put it to the back. And we said, oh, look, you know, we can do this after we've released and all the rest of it.

23:51But it was coming up so much that, you know, we thought, okay, we've got to pull it forward. And we were pretty chuffed because the first director we showed it to said, oh, my God, you solved a problem that no other tool has. Right? We're like, you know, and basically you could type half a memory and get back the exact pack of the page. And then people loved it in the demo. Like when I was talking to the initial people that were coming on and things and I'd do this demo, they would basically be saying, this is amazing. I've never been able to do this. Great. They started using the product and barely touched it, right?

24:30And I'm like, why are they using this? And it comes back to the original reasons that they were drawn to the product was this whole time pour. They're just trying to get this review done as quickly as possible. And so they actually would go straight to this key signals area instead. which did the triage for them and surfaced the risk and execution gaps and the positive things. And because a directed time poor, they don't want a better search box. They want the thing to tell them what matters. So I think this was the classic case of stated versus revealed preference. And it's very brutal when you experience it yourself.

25:10But stated is what people say when they can imagine having the problem and revealed is what they reach for at 10pm at night at 10pm on a Sunday when they've got the meeting on a Tuesday but these gaps don't show up in surveys and things so I think what I would do differently is I again hindsight is a wonderful thing I'd press harder in discovery on that bit and say you know give me three specific times you've tried to do this recently and tell me what you did instead because if it's annoying enough that they built themselves a workflow around that, then that's real. If they can't name a time, it isn't, right?

25:48So that was something I probably should have pushed a bit more to really say and make sure it wasn't just this, you know, potential problem.

25:58Randy Silver: It's easy for me to say that I'm not sure I agree with you on this because, and I'm going to throw out the challenge because I wasn't the one building it or dealing with it but i wonder if this is a classic kano model delider of the thing that helps in the demo and in the sale and that one time every couple years when you use it it's amazing but it's just not something that comes up or that it's not actually a day-to-day problem but what's your opinion on that 100 it was totally that it's it's almost i see it like one of those risk features right like you know it's there if you ever need it and you've done the tick mentally to say yep when I've got that problem it's going to be there but then if you don't have half the time you haven't got that problem because you're just trying to keep the review of your pack done the other there was another area similar to this where in the product we had this fantastic I kind of wanted people to be able to take a persona of different directors so you know because I've been in a lot of board meetings now and I'm the product and techie person, but a lot of the other people will go, wow, I, you know, I have no idea what any of that's about.

27:09And then I'll think, well, your legal stuff, I don't have any idea at the time what that's about. But what you could do was you could take the role of different directors and ask questions and things. And again, it was another area that people loved and you could, the first couple of times they would kind of use and play with the pack and get this really good interaction. And I think it actually made them really prepared for a meeting because they were taking questions from different angles and really thinking about stuff. But again, people were time poor. And so it was something that they just didn't use that frequently, but it was the Kano delight.

27:45Randy Silver: I could see that there would be a different user in that case of I'm the CPO or I'm the CTO and I want to prep for the meeting. So I want to take questions from practice questions from the board. A hundred percent. And that was exactly my view of this whole thing, Randy. I mean, you've nailed it, but people are type poor. So we're talking about things of perfect practice and it seems right, but the reality is people are just pushed to the line to get the review done and be able to get into that meeting. And they're not necessarily, even though we probably should, spending a lot of additional time to take these perspectives and things.

28:26So I call that sometimes the broccoli principle. I know I'm meant to eat broccoli and greens and all the rest of it, but it doesn't mean I do it all the time.

28:36Randy Silver: So what did you end up doing with these features? Did you keep them in and leave them because they were sold well and demoed well? Or did you decide that for the sake of relentless efficiency and keeping the code clean and things like that, that it's you know if people aren't using it we're going to cut it no we end up leaving now I mean Toby pretty ruthless with stuff like that like he was like let's get rid of it let's go but it was exactly as you said before one it was something that people were talking about still and wanting to see so dick the kind of thing and the rainy day feature and also with demoing well and we were probably still relatively early on our journey for you know not necessarily bloated with lots of features and things like that.

29:22We didn't build too way ahead. And that's the kind of, you know, it's the temptation, isn't it? And I've heard this with you and Faith on your weekly podcast where Faith's building her app at the moment. And, oh, my goodness, it's tempting to do this, do that, because it's so easy. But we were pretty disciplined with that and really said, look, these are the key jobs we're trying to support and let's make sure we've got those. and also to keep the product simple. So in the end, we didn't pull those because they were still seen as valuable. And again, it might be quite different. We were still quite early stage, obviously, as the product grows and is used in different environments.

30:04They might become more important as well.

30:06Randy Silver: So we were just talking about a couple of features that were used infrequently. One of the challenges you also had is this is a product that isn't used daily, weekly, or even monthly in a lot of cases, you have quarterly board meetings. And I've seen this in finance. I've seen it in education products in the past. But when you're trying to build and get feedback and build habits within things, how do you handle that with products that aren't used quite as often? They're used only when the problem arises. Yeah. It's the time to value a problem, right? And it's the one that, for us, could quietly break our financial model.

30:48And let me just give you a little context with that. Because when you're dealing with SaaS products and things, you're assuming fast activation. Ideally, you have fast activation. So someone sees value in a week and their habits are formed. And board software just doesn't work like that. Exactly as you're saying, Randy, it's boards are meeting monthly, sometimes six weekly, sometimes quarterly. and the value advisory came from memory across cycles and you can't feel that memory on day one so cycle one directors would run it alongside doing a manual read and checking whether it caught what they caught and cycle two they were still comparing but they were more confident and only by cycle three did they relax and start to rely on it and when we'd done our modeling I'd assumed two cycles in our model so for some but also I hadn't kind of gone through all these variations of all the the various boards um you know monthly is six monthly I'd kind of assumed six weekly not the quarterly there was even something that was six monthly it was like oh my god so for someone on two quarterly boards that's most of a year before their penny will drop and realize the value and then you try running a 30-day trial of a product that whose value shows up in a month in month nine you can't so it rewrites how you have to think about your trial your pricing your churn your assumptions and there's a harder layer underneath that like when demand is strong buying cycles collapse and i've seen products pull through procurement in weeks but this is the opposite kind of market and it's all about time to trust so this runs even longer than time to value because trust needs a comparison and the comparison takes cycles to build.

32:35So what I'd probably do differently next time or in another life is invest in a simulated second cycle view. And we had something like that in the demo with demo data, but people need to see it on their own packs for the penny to drop. And that moment was real. It just needed a faster way for people to get there. So they're all things that you just never think about when you're starting to get, and we know time to value, we know that we're looking for that. I didn't necessarily think about time to trust. Yeah.

33:11Randy Silver: And I see this a lot with people who are learning to use AI tools as well. The real value that comes from an accumulation of data, an accumulation of information, you get, You start to populate the MD files and you get to the point where the tool you're using has enough context to actually be useful. The more board packs and the more interrogation you've done in this case, the more value you're going to get out of it. But that doesn't go. Did you ever think about going back and populating with old packs and things like that? Or was that part of the onboarding in the first place? Yes. So the trial that we had a trial connected with that.

33:51And so part of it was allowing them to upload previous packs. But we put a limit on that as well because otherwise, again, people were just uploading stuff and you're paying for all of that and uploads and analysis and all the rest of it. So there's that line there between how much do they need to upload and see for them to see the value. And reality is looking at past stuff, people weren't really that excited. it it was the future stuff they wanted because it's gone right like it's done they're really in

34:26Randy Silver: the i was wondering if the past stuff actually gave the present enough context to be more useful or not but yeah they weren't it wasn't as engaging and i could tell they weren't as engaged as when it was the fresh pack that's when they really get into it because they've got to go into a board meeting pretty quickly nothing and it was funny right like in the system you totally knew when people's board meetings were coming up because there would just be this hammering on the weekends a couple of days before their their board meeting and things as well so definitely I think people are time poor they're trying to juggle a lot of things and they're trying to be as efficient as possible and so again it's one of those practices that you think about and people take the time and all the rest of it no you're kind of hammering in there at the last minute and it's the same thing with them trialing your product.

35:18So sometimes when I'd speak to people, they would say, my board meeting isn't until six weeks. I'm going to circle back to you then. So again, there's these long cycles of waiting until somebody's actually interested in using your product. It's the challenge with these type of products, like strategy products, I think are the same. If you're doing something that's only done once or two or three or four times a year, are, they're tricky products because you just haven't got people hooked and built that habit around them. They're valuable when they have to use them, but it takes longer for you to really prove that value.

35:57Randy Silver: So one of the other things that people have trouble with a lot, Kirsten, especially when you're moving from being in a CPO exec role to a founder or a co-founder role, is now you also have to take responsibility or full responsibility for pricing. So how did you approach it? This is a really interesting market that you're working in. It's, you know, it is people with money, but it's a new product category in some ways. It's not something that they had used before. So how did you approach this? Yeah, that's a great question. So I knew the anchoring trap going into this. And it wasn't a nasty surprise.

36:40It was a stubborn one. And what I mean by anchoring the problem was ChatGPT and Claude have set up a reference point for many people, right? At$20 US, they're paying for an AI analysis tool. And that's what they're comparing everything to. And Visory is not like AI, not like ChatGPT or Claude. It's a purpose-built, privately hosted in Australia, holds memory and director's insights across board cycles. And it's a completely different cost and liability structure. So we didn't try to explain how we differed from ChatGPT because nobody buys on spec comparison. We compared ourselves to the cost of a governance failure instead.

37:21So the liability a director carries into every meeting, the hours lost, as we talked about earlier, and grinding through a pack by hand. And so we moved people past the GBT anchor that would be there initially, but then created another one with our pilot price. So you think you're in the clear and then you do something else. And in a niche like we were playing in, it's not a volume game. You're playing a high value and you have to charge for it. And in our model, I basically modelled off$300 a board seat per month. So if you're on multiple boards and things, you're paying$600 for those two boards, for example.

38:02But to encourage our early adopters to start using the product, we gave them access at$150 a month per board seat. And I was definitely going to want it to charge and I wanted them to pay as early as possible because I wanted to know whether they saw any real value in this versus saying, hey, this was great, right? And I told them plainly it was early pricing and it would rise. now in theory you should be able to move people up as you position the value well enough and exactly as you said earlier that classic test of can you imagine if you didn't have this tomorrow what's it worth to you to keep this right so when we were ready to move beyond the pilot to general release I had those exact conversations with the pilot group and was trying to nudge them towards to the 300 and it was tough right and because 150 had become the anchor and the jump to 300 read as 100 % increase so I'd spend all my time worrying about this GPT anger and then went and credit and sent myself another one so the lesson here is either pilot a full price with a proper value case or pilot close enough that the step up doesn't feel like a penalty and I see this with people all the time like they go and do pilots with people and don't charge for it and then suddenly they try to put a price on it and it's a horrible discussion like it never goes well so you've got to I didn't do it as badly this is the friction one to get all over again isn't it would you be actually be willing to pay for this it is and so I was pretty clear on you know and we spent time and I'll tell you what it wasn't that easy stripe if you're listening to this your gateway is freaking it hard to get going.

39:49But we got that whole payment gateway and it was a little unusual, right? Our early adopters suddenly were saying, right, if you really want, they had been in an environment where we had been controlling everything and we knew the minute we switched over to them, we had to have all the privacy and security, all of that stuff. So there was investment in building that, but also the payment gateway because you can't really test if somebody's going to pay if you don't have that gateway. So all of that had to be built, which again, they were things that we were kind of testing the signals in that before we'd go and invest in those things.

40:24But it was a really, this anchoring thing, we got money, but it was half of what I'd modeled and it was still good. Like people would say, wow, you're getting under 50 bucks a month for me. Well, that's not bad. It's a niche market, right? So you need these people paying more for something that's highly valuable to them as well kirsten this has been

40:45Randy Silver: hugely interesting and really valuable the lessons you kind of speed ran through uh an entire building a company and exiting cycle and in doing it no we are we are doing more don't worry don't worry um but i had i want to ask you about advice you would give and some of the bigger lessons you learned. So in two contexts, first is you and I both worked on the Maker's Manifesto together and kind of an evolution of the Agile Manifesto, what some basic principles for building in this age. What were the things that were really important to you? What did you really want to see in this? And what is the more general advice that you are giving to everyone as a result of this experience?

41:35I think what people get caught up with building, and I'm seeing this time and time again, is distribution is the product problem right now. And you can't defer it until you've found product market fit. People get so caught up in the build and is the product desirable, usable, all of that stuff? Not can we get it to people. And even, I think it was Evan Spiegel who co-founded Snapchat, wasn't it, highlighted this really well for me. He was like, everyone's obsessed over product market fit and barely thinks about distribution and distribution's getting harder. AI has collapsed the cost of building, but it hasn't touched the cost of reaching people who trust you.

42:18So what I did was I treated the channel as its own hypothesis with its own tests and its own stop criteria right from the beginning because the channel had to mirror the customer and in so in my case you know directors aren't browsing apps or answering to outreach they act on recommendations from someone they trust and so for me a founder with a laptop no matter how good the product is there's a trap there right if I think that they're going to just buy from me based on that. So I really think it's one of these things that I'm seeing people underestimate the distribution side continuously and they're getting caught up in the build and saying, hey, we'll do this.

43:03And if we build it, they will come, which Randy, you and I have seen many times.

43:08Randy Silver: Those are all outputs. If we can build it, that's an output. We've successfully pushed something into production. That's fantastic. but the outcome is successfully getting people to use it and pay for it, creating value for them and for us. It's totally that. So for me with the manifesto and I was part of contributing to the work that Faith led, it's probably the part that I pushed for the hardest was around distribution. And because we're always saying build the right things and build it right, but that third discipline about getting the right things into the right hands, I think it has equal weight.

43:42And it's things like distribution, adoption, willingness to pay, retention, none of that's downstream anymore. It's a learning loop. You need to run as early as you're doing the rest of your product discovery. And so for me, that was a really critical part to come into the Agile Manifesto. And it's something that I felt quite passionate about. Okay.

44:03Randy Silver: So that's a good general lesson for everybody, if you were tempted to do a startup again, or you see a friend of yours who hasn't done it yet and is ready to go down the path, is there anything specific that you'd say, this is the thing that I went in knowing this. If I was doing it again, I would do this differently. Building the thing is never, it's never been easier. So you've got to do the hard part. You assume that you're not the customer and you've got to find out whether anyone is willing to pay. That's why I love you nudging faith all the time in the podcast, really out loud of, have you got anybody to pay for this?

44:43And I think what I talked about with putting friction in their way on purpose to see if they'll push through that to get to your product is something that I think everybody should think about. And it will be different for the types of products we're dealing with obviously because liking is not boring the build is cheap it's the actual the commercial questions is where most of things these things die quietly and they're the one nobody puts on the highlight wheel so for me the sooner you get to testing that commercial side don't get caught up in the vibing and the how beautiful these things are that you can create test the commercial side and I do like you Randy a lot of advising and it's the thing that I constantly have to push people on because building it is very comfortable right getting money out of people is it and getting to the right people to buy your thing is hard as well so give equal importance um the other hindsight things I think it's it's pretty as I said earlier it's these environments are very relentless and so for me it was I think we underestimated that we could build things so fast and do all of these things and the toll right like for me I was pushing ahead but Toby at one point said I'm getting really tired and it's not that he's a slouch or anything like that it was it relentless so you've got to be mindful that you know I suppose there's a conserving your energy and focus and things but it was it's something that i think is only going to get worse when you as you can do more and more things you know so it's probably something i would say to people be a bit mindful of that in these environments but i also find that part of the

46:34Randy Silver: problem with that is every time i sit down to to fix something in the stuff i'm building it feels tantalizing and close it feels like it's only going to take 10 minutes and then hours later you're still sitting there to refining it and getting it just quite right and you it's in the past some of the work was predictable you know you knew so some of this stuff was just going to take a while to do but every now you're fooled by how quickly it could happen it's totally it's your tantalizingly close statement is so true and honestly there was we people saw what we built like when I first spoke to the early adopters to when we went to market it was about four months right and when we had if I'd done this product and I have done a lot of products if I'd done this in a previous life it was an 18-month build for sure and a team of eight engineers and all the challenges that come with that now so people were like almost it was like is this going to be any good because it's been so quick but that four months it wasn't me doing a nine to five it's exactly what you said ready I was like oh we're so close if I do if I do this for another hour we'll have this whole thing over the line and we're done and it was really interesting I had another friend who was kind of um bouncing with me on the side and it is fantastic product leader as well Rachel Morley and some and she wasn't necessarily in the thick of what we were building but she was great to bounce and advise and was looking at some of the marketing side of things.

48:06And sometimes she'd get frustrated, like, why haven't you done that? Like, what's going on? Like, you talked about exactly what you talk about with faith. And you know because something's so close but then it's not 100 % right. The other thing I'd say, actually, another lesson that you've made me just think of as we're talking through, I think this space is actually getting harder and harder in AI as well because models are drifting. and we found this as we had to invest more in the emails around the system and watching it so again I think the build part is really quick it's the QA framework and the testing framework that you've got in getting place if you're trying to commercialize this that is hard and staying on top of it and all the rest of it so that's the other part I think people forget about and I see this a lot too like people go and put these products out get people using on and it might be a it might be something that's not mission critical that's okay right if it's something that people are going to be reliant on you have to make sure that quality is there in the testing and also testing the models because they do drift what I'm seeing is people talk about

49:21Randy Silver: evals and to me it's still like test driven and behavior driven design it's an evolution of of that attitude and what you're doing but because these are non-deterministic tools uh because they are black boxes you have to treat them and not to anthropomorphize them but you have to treat them like an employee and do regular reviews and and calibrations and and things and people forget that we still think of it as pure software when it is not non-predictable sometimes and we need to yeah and it's always the way right like if you cut a corner somewhere it comes back to want you in another place and it's so this is this is the part where people I think they're not thinking about oh I've got this thing to market and blah blah it's like well you know the minute you do a feature you're gonna have to go and do regression across the rest of it right and all of this stuff that we know what we have to do in software doesn't go away it might be easier it might be more automated in certain parts but you still have to watch those things and And so understanding the data and what's happening in the system and having ways to be able to see and test that and designing that from the outset is equally as important as building these things.

50:34The other thing I think that bit asked a bit, I heard your example with Faith around, you know, she left an agent running and dragged her bag of guard and everything. And we had a couple of situations, but it was slightly different, where in the product, we used multiple models to test the analysis. So one model would do an analysis of the pack, another model would do another, a totally different model would do another analysis, and then a third model would adjudicate on who had done the best work, and that would be selected. And one point I was looking at the, and again, you want environments, and this is what Toby had set up, where we could see what was going on with all the calls and all the rest of it.

51:17and at one point we were looking and we're saying why is it all there was a couple days where it was picking one model all the time and we're like why is it doing that what's going on there well that the other model had just been retired overnight so the was that we saw with mobile where we used to complain and say how hard it was to get something in the apple store and a pain in the ass or what they're not existing now right and and these providers they just deprecate their models they might do this random email that nobody sees and suddenly it doesn't work and you've got to be staying on that now again you can do feet you can do feature work that detects all of that we didn't necessarily want to invest in all of that type of detection initially when we were kind of trying to test viability but it was really interesting of how quickly this space is changing

52:08Randy Silver: and how much you have to be on it to because it'll fix it's getting higher and higher oh man and it's exhausting. So I totally empathize with everybody in this space during this work. Kirsten, this has been fantastic. Congratulations on building a successful product. And thank you again for coming on to share all the lessons you learned from the process. Thank you for having me. And hopefully I haven't been too naughty this time. The product experience hosts are me, Lily Smith, host by night and chief product officer by day. And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work.

52:53Luron Pratt is our producer and Luke Smith is our editor.