Today I’m chatting with Yuval Gonczarowski, Founder & CEO of the startup, Akooda. Yuval is a self-described “socially capable nerd” who has learned how to understand and meet the needs of his customers outside of a purely data-driven lens. Yuval describes how Akooda is able to solve a universal data challenge for leaders who don’t have complete visibility into how their teams are working, and also explains why it’s important that Akooda provide those data insights without bias. Yuval and I also explore why it’s so challenging to find great product leaders and his rule for getting useful feedback from customers and stakeholders. 

Highlights/ Skip to:

• Yuval describes what Akooda does (00:35)
• The types of technical skills Yuval had to move away from to adopt better leadership capabilities within a startup (02:15)
• Yuval explains how Akooda solves what he sees as a universal data problem for anyone in management positions (04:15)
• How Akooda goes about designing for multiple user types (personas) (06:29)
• Yuval describes how using Akooda internally (dogfooding!) helps inform their design strategy for various use cases (09:09)
• The different strategies Akooda employs to ensure they receive honest and valuable feedback from their customers (11:08)
• Yuval explains the three sales cycles that Akooda goes through to ensure their product is properly adapted to both their buyers and the end users of their tool (15:37)
• How Yuval learned the importance of providing data-driven insights without a bias of whether the results are good or bad (18:22)
• Yuval describes his core leadership values and why he feels a product can never be simple enough (24:22)
• The biggest learnings Yuval had when building Akooda and what he’d do different if he had to start from scratch (28:18)
• Why Yuval feels being the first Head of Product that reports to a CEO is both a very difficult position to be in and a very hard hire to get right (29:16)

Quotes from Today’s Episode

• “Re: moving from a technical to product role: My first inclination would be straight up talk about the how, but that’s not necessarily my job anymore. We want to talk about the why and how does the customer perceive things, how do they look at things, how would they experience this new feature? And in a sense, [that’s] my biggest change in the way I see the world.” — Yuval Gonczarowski (03:01)
  
• “We are a very data-driven organization. Part of it is our DNA, my own background. When you first start a company and you’re into your first handful of customers, a lot of decisions have to be made based on gut feelings, sort of hypotheses, scenarios… I’ve lived through this pain.” — Yuval Gonczarowski (09:43)
• “I don’t believe I will get honest feedback from a customer if I don’t hurt their pocket. If you want honest feedback [from customers], you got to charge.” — Yuval Gonczarowski (11:38)
  
• “Engineering is the most expensive resource we have. Whenever we allocate engineering resources, they have to be something the customer is going to use.” – Yuval Gonczarowski (13:04)
• When selling a data product: “If you don’t build the right collateral and the right approach and mindset to the fact that it’s not enough when the contract is signed, it’s actually these three sales cycles of making sure that customer adoption is done properly, then you haven’t finished selling. Contract is step one, installation is step two, usage is step three. Until step three is done, haven’t really sold the product.” — Yuval Gonczarowski (16:59)
• “By definition, all products are too complex. And it’s always tempting to add another button, another feature, another toggle. Let’s see what we can remove to make it easier.” – Yuval Gonczarowski (26:35)

Links

• Akooda: https://akooda.co/
• Yuval’s Email: y@akooda.co
• Yuval’s LinkedIn: https://www.linkedin.com/in/goncho/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Yuval Gonczarowski, the CEO of Akooda. Welcome to the show. How are you doing?

Yuval: Thanks, Brian. It's a pleasure to be here.

Brian: Yeah, so you’re dialing in from Israel right now, but Akooda is also based in the East Coast, in Cambridge, probably down the street from me somewhere. Tell my listeners a little bit about Akooda and also what a socially capable nerd is. I love that in your [laugh] LinkedIn.

Yuval: Thank you. Oh, start with Akooda. So, Akooda is what we call the world’s first operational intelligence platform. What we basically try to do is, you know, when we think about the future of work, we always see the need to give everyone more access to the company, to the data that company holds and what we’re actually doing, why we’re doing what we’re doing, how much time we’re dedicating to our biggest challenges. These are things that managers think about things that individual contributors, developers think about.

And so, what we try to do is provide this glue that used to exist in watercooler chats and informal connections and adapt that, sort of, to the new reality of either being fully remote hybrid or just a big company that’s outgrown garage mode. Socially capable nerd. I mean, I—so both my parents are AI professors. I grew up writing code before I learned how to ride the bicycle and I’m still not a very good bicycle rider. But you know, having spent six years of Israeli military and four years in management consulting, I’m still deep down inside, a true data science nerd. But someone just referred to me one day as a socially capable nerd. And it—

Brian: [laugh]. No, I get it. There are some other of these, they get called soft skills. I don’t think that’s the right label for them, but just, I’ll use it because I think the audience knows what I’m talking about here. You worked at Apple for a while; you had a stint at the Media Lab I saw.

You know, obviously you have to have some pretty serious technical chops for all that kind of work. Did the product role and running the business, is that something you just found very natural, and you evolved into that or did you have to consciously learn some different skills and maybe turn off some of the technical skills sometimes and turn on some other ones? Tell me a little bit about—and I assume you’re sort of running product as well as running the business at this stage of where you guys are at.

Yuval: We do have a phenomenal head of product, her name is Roni, but she’s also comes from that path of being a former developer and transitioning into the product role. What you just said really resonated with me about sort of turning off some skills. I think that is the number one thing that I found I was doing more, and even kind of surprised me is when I have a discussion with my CTO, my first inclination would be to ask—you know, straight up talk about the how, but that’s not necessarily my job anymore. We want to talk about the why and how does the customer perceive things, how do they look at things, how would they experience this new feature? And in a sense, I think that’s my biggest internal, I don’t know if struggle, but my biggest change in the way I see the world is it’s I just have to shut this part of my brain that constantly reminds me how I can solve these challenges, and first and foremost asking myself, “Why is this a challenge that is worth solving?”

Brian: And I’m going to give the audience a little bit more information about what Akooda is. I’m always trying to think in terms of use cases and problem spaces, right? And the one I got from this was, does someone in my company, that maybe I don’t even know them, have a skill set or some information about something that I might need? And your tool going out and monitoring and scraping data from all these different sources is able to see, like, “Oh, so-and-so knows a lot about”—we joked about, like—“Building a churn model.” It’s like, “Oh, good. We don’t need to start from scratch. Someone else is doing one of those.”

So, it’s for finding that skill set and also for management to know, oh, we’re spending a lot of time on this kind of thing, and there’s three people doing that. And I thought only one person was, so maybe we don’t need three teams working on that. Am I correct so far, in some of these use cases?

Yuval: I talk to a lot of managers, managers being from, like, project managers, product managers, all the way to company managers. In my mind, a manager is anyone who needs a horizontal perspective of the organization. And when I talk to the manager I ask them, “What do you need to do your job well?” No matter how I phrase that question and attack it from different directions, the answer is always going to be somewhere around data: the right data, more data, more visibility. Take any CEO and say, “What do you need to do your job better?” Any project manager, “I want to know what’s the status of this,” right?

It all revolves around data. When you ask an individual contributor, “What does your manager need to do to get their job done?” It’s also going to be data, but it’s going to be attacked from a different perspective, right? And this is where the whole, like, concept of nobody wants to micromanager, comes. And so, how do I give or surround myself with the right data—myself and my peers, my managers, my colleagues—with the right amount of data so they can call the shots or make the right decisions, but in a way that makes us all move in harmony?

The way Akooda approaches this problem is very much data-driven and data-centric. Let’s take, you know, this conversation, for example. Let’s say we’re doing this interview on Zoom, right? So, we’re in a Zoom call of Brian and Yuval Talking about Akooda or talking about Experiencing Data. It doesn’t really matter if we have this conversation on Zoom or on Slack or in a Google Drive document that’s called ‘Akooda’ that we both edited and annotated together, right, customer support ticket or anything in the digital footprint. It’s a conversation between two people talking about Akooda, and we dedicate a certain level of effort to it and time and significance.

And what our engine does is we take the entire digital footprint that the company produces—of course, public digital footprint—we break it down and then we build it back up in a way that makes us, enables us, to ask the right kind of questions. So, now we can ask, “How much time are we spending discussing Akooda?” Like, “Who knows the most about Akooda in the organization?” I can find the document, but I can also say, “Brian does because he spent a lot of time on it.” And so, once we have that kind of mapping the organization of the information that flows around us, we can help provide this additional layer of insights that benefits both managers and individual contributors to align themselves then the organization a lot better.

Brian: If you’re selling this into a bank, or a large enterprise organization, there’s so many people there—and the use cases of, like, I’m a developer on one team building a feature, an API for this product team who is part of the digital team who’s part of the whatever team, we’re talking hundreds of thousands of people here, the use case of that individual developer doing something versus the VP of marketing or something at the level that they’re looking at, maybe meant managing hundreds or even thousands of people, those use cases have to be fairly different. Is it meant to support all these different management tiers, as well? And if so, how do you keep it simple enough that it’s not kind of a B-minus experience for everyone because it’s trying to satisfy everyone’s needs? That’s one of the design challenges, like, well, who’s it for, right? And when it’s for multiple people with multiple different use cases, that’s what’s really hard to design for. So, how do you approach doing that?

Yuval: So, we spoke about sort of this data tree that we build or these fundamentals of taking the digital footprint and dissecting it into these units of work. A manager doesn’t necessarily—or, like, a high—a senior executive, what they want to know is the train is moving in the right way. So, they’re kind of questions are going to be, for example, “How much time are we spending with, I don’t know, the long tail of customers compared to the bigger enterprise tickets?” Or, you know, “If I have a customer that’s only paying me, I don’t know, $10,000 a year, which is a relatively small amount, but 8% of my R&D team’s time is going on developing features that only that one customer uses?” Those are kind of the questions or the queries that these executives are going to have of the data.

And this again, goes back to me being the nerd part of the socially capable nerd. The databases behind that are the same, right, which is understanding the digital footprint and making sense of it. The individual contributor is going to say, “I’m now working on self-serve login or API access. I want to see all relevant information around that. I want to see, one, what the documentation is. Maybe I want to avoid these stale documents that we all know exist, but are no longer relevant for anything.”

But I also want to maybe have a set of eyes on the sales calls that mention this because I’m a developer; I don’t want to work in my own silo. I want to see how sales teams are bringing that up in their calls, I want to see all the marketing folks are going to treat it. And all of a sudden, we get this magic of I now have the visibility into the things that I’m doing down the line or up the line from me. And, you know, our customers, they love it because it creates this sense of bond. Because it is harder for me to go into the water cooler and talk to the marketing folks, and, “Oh, we’re working on the same thing? That’s pretty cool.” But once we have that visibility through the NLP engine and the AI that combines these two sources into one unit of work around self-serve login or whatever it is, that’s where magic starts to happen.

Brian: How do you test that the use case is designed for say, you know someone at the C-level person that’s looking at am I giving enough love or the right amount of love to customers based on the revenue that maybe is coming in or something like that, versus lower-level manager or something like that? How do you design the product around these different use cases for these different people?

Yuval: The name of the game here is dogfooding, right? We are our own biggest customer. If I spend too much time on spending the feature that spends too much time. There’s a lot of meta in our discussions when we take a look at our own product on our own company, right? When I demo Akooda, I show people Akooda on Akooda.

We are a very data-driven organization. Part of it is our DNA, my own background. When you first start a company and you know you’re into your first handful of customers, a lot of decisions have to be made based on gut feelings, sort of hypotheses, scenarios, I’ve lived through this pain, and I’ve been in very large organizations for most of my career, Apple, Intel, McKinsey, others. I kind of know this mentality, but you know, the more customers you bring up and ramp up and have them on board, data-driven design, I think is one of the key most important things for a feature like this. I want to see that my biggest customers are using the features that I thought I would be building for them, and they’re also allocating the right amount of resources to ask these questions.

If they’re not doing that, and we have had cases where, you know, I thought I was building this killer feature that everyone’s going to start using, but they just haven’t logged into it. So, U-turn flip, change direction, change resources, and build something else. I do think this is the only advantage that startups have over large companies. It's speed, right? Acknowledging that we maybe made a mistake, or developed a little feature or widget that’s not being used by customers, scrape it back to the drawing board, build something else our customers are going to love.

Brian: Sometimes lack of use can be a variety of reasons, like, I can’t find it, or it’s not labeled properly or I thought that was for somebody else. There’s a lot of reasons where maybe the underlying idea is actually pretty sound, but the execution is odd versus this is just a solution in search of a problem. It’s a chart in [laugh] search of a problem. Do you do any type of one-on-one research with customers to get stuff in front of them before it’s fully built, or do tend to ship and then see what sticks and then pull stuff out?

Yuval: Really strong opinions that I have here that may be a little bit contrarian to what they teach in product schools. So, I’m happy to get the pushback. I don’t know if it’s the best or not, but for one, I never do unpaid pilots, I charged for the customer when it was me showing, like, this quick and dirty me running through the data and showing you a visualization on Zoom, and I charge now when it’s a self-serve plug-in that you can jump into. I don’t believe I will get honest feedback from a customer that I don’t hurt their pocket. That’s the number one we’ve done since the moment the company was founded, even before we got VC money, and I will do that for as long as we can, I think.

You know, if you want honest feedback, you got to charge. And so, that’s one thing we’ve been doing. But we do sometimes give a little bit of a discount for a biweekly meeting that is product related. And I think that’s one thing that product people sometimes don’t judge probably is, you have the customer success meetings. The purpose of those are making the customer the happiest they can be.

But you also want designated product discovery settings, meetings where the customer knows now they’re here to help you. And one of the things we started doing—and this is a tip I got for one of my mentors—is whenever one of our customers were really instrumental in helping us design and develop a feature, we actually name that feature after the customer.

Brian: [laugh].

Yuval: And you know, so we have, like, the Stevie feature, or the Dee feature or, like, customers that really help us design the platform in the best way possible. And then they feel part of it too. And then all of a sudden you have your real champions inside the product.

Brian: Do you prototype things first, either in static mockups or some kind of low fidelity before you commit engineering to it? Or do you kind of jump right in and wire it up fairly substantially with data behind it? Or talk to me a little bit about how far do you go before you’re ready to commit putting something in.

Yuval: There is, of course, I think one right answer here. And that’s that engineering is the most expensive resource we have. Whenever we allocate engineering resources, they have to be something the customer is going to use. What we do here at Akooda is we have what we call our front-running team, led by Amitai. He’s a phenomenal data scientist.

And sometimes what he will do his work through the databases, or more than the back-end layer, and create these dashboards that are not fully in the product, yet show it to a subset of the our customers and say, “What do you think? Maybe you can play around with it a little bit.” And then when we see growing engagement, we sort of go back to the drawing board and build this for scale. And we call it [unintelligible 00:13:35] front-running team.

Brian: I assume, like, if you’re building a feature out, the assumption is, well, here’s this problem that this thing is supposed to solve. Do you run them through some kind of task or, like, a job to be done that they have to try to use your tool for or is it more open qualitative feedback? Do like that kind of thing? How do you approach that?

Yuval: I’ll share an example. We all know how different, I guess, the second half of 2022 was from the first half of 2022 in how we run companies and allocate resources, you know, transitioning from growth to profitability. About seven or eight months ago, one of our customers reached out and said, “I had a company walkout. It’s an entire team, basically. I know Akooda can help me, I’m just not sure how. I know you have digital footprint analysis, you can help me recover, maybe understand if there are any open points of work or, like, I know you can. I’m not sure how. I’m lost here. I have to go scramble and find open projects and talk to the team and do all these things that I can.”

And then what we did was we tried to do some of these product discovery sessions and said, let’s think together about how we can, you know, attack this use case. And we came up with what we call an offboarding report, which is the understanding say if there’s any open meetings that are now don’t have an owner or customers who no longer have a rep that is actively working on or some alerts or things like that, you know, because you lose people, you also lose some information and documentation. And then, you know, you roll something out. You say, like, “Here’s a couple of queries that I ran on my database. Is this something that’s helping you solve your problem?” And they say, you know, “I like this part. This part kind of useless.”

We go back, we do another iteration, and then we have these amazing customers who are going to give us that feedback until we nail down how we see these things happening. And then we’ll take it to production, right? We say, like, now you can just click and see everything you need around a specific event or a customer, and now anyone can do that using the product. And it’s one of our most beloved features.

Brian: The offboarding?

Yuval: Yeah, offboarding, or just, like, show me on a project level on a timeline, how much progress we’re making, or if there are any sort of things that we don’t see a clear owner attached to in the digital footprint.

Brian: I know as a designer, the one thing I’ve learned over the years is that the person that’s being sold to, the customer, is not always the user of these tools and there can be a disconnect between the value conversation that you’re having with the buyer versus everyone else that’s going to be quote, “Stuck with it.” Hopefully, they’re not stuck, right [laugh]? If it’s doing its job, they’re actually, like, I love this, I couldn’t work without it. Do you ever see a gap there between the person buying it and what people are actually trying to do in the field?

Yuval: So, when I think, you know, measuring expansion metrics inside of an organization was one of the most important things we can and should do. We have these internal metrics of, you know, a certain number of weeks in, we want to see 5x, 10x growth in the number of users internal to the organization and I want to have a few champions. And one of the reasons why Akooda is very good on these metrics is because we pay close attention to it. I do think if we want to sell B2B SaaS today, we always have at minimum two champions, which is your buyer and the CFO. The CFO is never going to approve a line item unless they can actually see a benefit for themselves in the [unintelligible 00:16:39].

And so basically, if we want to create a good sales cycle, we have to sell the product to our buyer, our user, the champion, and then we have to sell it to the CFO. And then sometimes you also have to sell it to the head of IT because they’re the ones who are going to install it. And it can be misleading, right, because you essentially have a sales cycle after you’ve sold the product. But if you don’t build the right collateral and the right approach and mindset to the fact that it’s not enough when the contract is signed, it’s actually these three sales cycles of making sure that customer adoption is done properly, then you haven’t finished selling. Contract is step one, installation is step two, usage is step three. Until step three is done, haven’t really sold the product.

Brian: Do you ever see a disconnect, though, between once you get into the usage, what teams are doing or what they want versus the thing that the customer that wrote the check was looking for? I would imagine at the higher levels they’re really probably thinking more about, “Am I spending the right amount of time on the right things?” At the individual contributor level, there’s probably less concern about that, right? “It’s my job my thing, my project I’m working on.”

Yuval: I don’t think for us, it’s necessarily a problem because our buyer is go top down. We start with operations leaders, VP Ops, COO, and these are the kinds of challenges they face every day. “Where’s my company going? Am I allocating the right resources? Is that is that project going to be on time? Where can I find the information today?”

I think that the most commonly used phrase by an ops person is, “What’s going on with x?” But there’s always the surprise and delight element, you know, when someone finds out that you have this amazing insights tool inside your organization and you haven’t heard of it, and then you just enjoy using it. Yes, we provide value to a lot of folks that aren’t necessarily our first touchpoints.

Brian: I kind of have this theory that nobody really wants machine learning analytics, that they don’t really want insights, right? Usually it’s, I have an itch that I need to scratch. I have a sense that maybe we’re not using our time well—like, and I’m making this up and I’m thinking about your scenarios—ultimately, they’re trying to decide, “Can I rest easy that everything’s on track or do I need to change something?” So, the question is, when you think about this, are you designing for just that decision support which is the action that would follow, or do you tend to think more about, we’re just providing the facts, and whether you’re going to make a decision on it is something totally else, or designing for the decision part of the way you position the product? They’re a little bit different.

One’s about putting the evidence in front of people. The other ones about do I need to change something. “Did you know you have 15 people building churn models in different departments? Is that correct?” “Oh, yes, it is.” “Okay, then we’ll just not talk to you about that. That’s fine.” Or “Wow, no I didn’t know that and that’s abnormality. That sounds like I should take care of that. That sounds like waste.”

Yuval: Let me share two stories and an analogy to answer your question, right? So, the first story is June 2020, right? So, this is—and the company has started yet, but it was just me. We haven’t fundraised yet, so I was just writing code and showing it to early customers that paid me, like, $200 a month.

And I spoke with one of our design partner’s early customers, and we showed, we recognized, using digital footprint analysis, that there’s a silo of about four to five people in the organization that they’re not as connected to the rest of the organization as everyone else is. The COO tells me, “Yuval, this is amazing. Do you know why? Because all of those people started after Covid, right? June 2020, all those people were hired right after we just went fully remote, no longer in the office. Something in their onboarding wasn’t right, or we’re not seeing them as cohesive because, you know, we lost the in-office charm.” And you know, “I love Akooda because you just gave me an action item, right? I need to go talk to these people and help bring them inside the organization. I know what I need to do. Great.” Awesome aha moment for me in my very early days trying to start a company.

A couple of weeks later, I talked to another one of our customers, a COO, and we see another silo in the corner. I thought I was being smart asking her, “What, did all those people start after Covid?” And she tells me, “No Yuval. That’s my PhD research team. They’re working on projects the company is working on five years from now. I’m actually extremely happy that they’re siloed because I don’t want them to get sucked into the day-to-day of the roadmap. They’re my finest engineers, but everyone else can handle these routine events that are happening. I want them solving my most difficult algorithmic problems. I love the platform that you’re building. But I love it because here now you’re showing me that I’m doing the right thing. Because we had a problem with those people getting too much into the day-to-day and now they’re being siloed.”

And so, those are the two stories that the analogy is from one of our advisors who gave me the Tinder analogy. I lost the world of online dating because I got married very early, but in Tinder, if someone doesn’t get a lot of matches, they get the following notification. “You haven’t changed your profile picture in a long time.” Tinder can’t tell you, “Hey, man, you’re not too good-looking. You might want to change your picture.” [laugh].

They can’t tell you that, right? So, it’s going to give you a data point and that data point is you haven’t changed your profile picture in a long time. It’s non-disputed, it’s available. Tinder is limited in what it can tell you. It’s an app. You are you, right?

What we want to do when we talk about organization, operational intelligence, and insights, is never going to tell someone, these employees are siloed because they shouldn’t be. I’m not here to replace your job as a manager to say, is this a good thing? Is this a bad thing? True insights come from the fact of also Akooda recognizing its spot as operational intelligence. So, we are the glasses, we’re not the eyes.

And so, there’s a certain level of insights that this information provides you. We’re not talking about a blank dashboard and analytics that you ask, “Well, why is this showing up here?” But I also I’m not going to tell someone, “Here’s an employee who’s about to leave,” because who am I to tell you that an employee is behaving the way they are because they’re going to quit? That’s wrong and very presumptuous of me.

Brian: Do you tend to think about it as in both cases, there was a small group of employees that was distinct from the others, and it was a group—or maybe they didn’t even know each other but they all shared some common characteristics, right? In one case, they were isolated and the other one, they were isolated on purpose—is even pulling out the fact that you have some isolated people, though, a signal that you would push to customers, which is, “Hey, we’re detecting you have some siloed people,” that at least identifies that there’s something anomalous about this collection of people over here. And that suggests that you guys have thought through the use cases which are, silos can mean something really important, so the product should do that work as opposed to simply relying on eyeball analysis. Is that the tool’s job versus the user’s job to go dig through it, right, because one of them’s about eyeball analysis and humans doing all that digging, versus the tool is looking for these patterns and pushing them to the surface?

Yuval: I don’t think there’s one clear approach here, right? It’s just like any managerial challenge, right? Even in my day-to-day as a CEO, some of these things that I approach proactively in saying, “All right, here’s this project I now need to look into, or a question or a hypothesis that I have.” But then I also want to get these push notifications if things aren’t working. If the product is down, I need my team to tell me. I don’t need to search for if the problem is down every day.

But if I want to go to give this directive like, “We should focus on these five key customers and make sure we don’t drop these contracts, or we don’t drop these efforts,” the push versus pull model. And Akooda does both, right? You can log in, hand out these queries, say, “Show me the organizational chart, the comm chart. I want to see if I can find any silos, et cetera.” But you can also say, “I want to make sure that the time I spend on building new features is always 30 or 40 or 50% of the time level of effort of my organization.”

And that sort of relays this information back to you and a pull mechanism if it is or is not the case. It’s a case-by-case thing of when is it research mode of me logging and trying to optimize my organization versus when am I already expecting the platform to highlight things that aren’t functioning properly for me?

Brian: There was an old joke when I worked at Lycos 20 years ago. Once a product manager gets something on the homepage, you can’t get it off. Once it’s there, people fall in love with their widget or their feature or whatever. Any big lessons you’ve learned about either we had to remove something even though we were convinced that this would be so awesome. What was the process and when did you learn that it’s time to pull the plug or it needs to be redesigned? Is it tough to swallow that pill when the team feels like it could be so great, but you’re not getting good feedback on the usability or the utility of that?

Yuval: That is a great question, Brian. Thank you. I’m very public about my values and principles and leadership philosophy that I have. It’s the pinned post on my Twitter, my internal set of values that I go with on every employee. And one of those values I call truth.

And it starts with a quote by Ray Dalio saying that truth, or more precisely, an accurate understanding of reality is the essential foundation of any good outcome. And it means that we have to value the truth even when it’s unpleasant. Avoiding internal biases or the sunk cost fallacy of look, we spent six months on it, so we have to put it in the front page, I mean it’s the number one thing we have to let go of. We’re going to try to minimize those mistakes like we said earlier. Front runners, we want to make sure that everything our engineers do is going to be there and create these aha moments for our customers.

It’s never going to be at a hundred percent. We’re going to scrape features. It’s going to happen and we have to be okay with that. Want to do it in a pleasant way and make sure that we keep the motivation high. If I did something that’s not giving me the right results I wanted it to, then we have to acknowledge that. Sometimes less is more, aka Google front page versus Yahoo front page.

Brian: The pushback I hear is the antidote is data literacy. So, the issue is, my stakeholders or my users aren’t data literate enough to know how to use the solutions that I’m giving to them. What’s your position on that, having two parents [laugh] with AI professors? And how much is it the customer’s quote, “fault,” or their need to come up to speed, to understand this stuff versus know the product is not simple enough; we need to make it easier or whatever?

Yuval: I think the product is never simple enough.

Brian: [laugh].

Yuval: Right? Think about the iPhone. So, much to just make it one button and then even remove that one button. By definition, all products are too complex. And it’s always tempting to add another button, another feature, another toggle. Let’s see what we can remove to make it easier.

How many people actually use the, like, trend screen on Twitter other than make a joke out of it? There’s so many things that, like, Google Drive has so many features hidden under their settings that no one’s ever used, but we like it because it looks like the Windows folder and we can click on these documents and have a search function capability. And everything else can be hidden under, like, menu option number five or six. And I think it’s the same thing for all insights, analytics tools, whatnot. Providing simplicity and starting you know, in the Jobs to Be Done Framework explained very well by the lathe, Clay Christensen, who was an incredible human being, is what is the job to be done? And how do I answer that job to be done with my platform? It doesn’t have to be through 20 different configuration settings and then 50 buttons. It can be just one really good one.

Brian: You mentioned a really good thing we’ve talked about on the show and this is subtractive design, right? It’s, where can I remove to simplify? We tend to think about, “I need this to stand out. Well, let’s make it bold.” Well, we could just reduce boldness everywhere else and let that thing stand alone, and so that’s usually my recommendation when clients are coming to me with complicated dashboards.

It’s like, “Well, what’s not really necessary here? How can I reduce some of the ink that’s here to let the most important things stand out?” That tool [laugh], the knife or the scalpel, it gets lost a lot of the time. We’re tending to think about what do we need to add, you know, to make things easier [laugh].

Yuval: I want to say it was Mark Twain, maybe it wasn’t Mark Twain who said, you know, “I didn’t have time to write a short letter, so I wrote a long one instead.”

Brian: [laugh]. Totally. So, the short ones are the tough ones. To get a lot of signal packed into a short amount, you know, it’s tough [laugh]. I can totally relate. If you could start over right now with Akooda, with the product or this product strategy or any of that, is there something you change, anything you’ve learned in the couple years you guys have been rockin’ and rollin’?

Yuval: I think my biggest mistake is it took me a year to hire the first head of product other than myself. In retrospective, I would have done that earlier. My head of product, we worked together at another company, so we’re very much aligned in our world philosophies, but two is better than one and it’s always good to get that product push back, so I think that’s one thing I would have done differently. And then the second thing is, anytime you invent the category, you’re bound to, you know, walk into a few different doors and then do the U-turn, walk into another door.

It’s like writing code, you know? You have bugs, you fix them. In retrospective, I would have written that clean code directly from day one, but sometimes the process is inevitable. One of the things I’m most thankful for is our early design partners and believers that are very much the third product arm other than myself and our head of product. They’ve been giving us this extremely important feedback to build the things that they love.

Brian: You maybe remind me of a question I wanted to ask you, which was, is there something different about hiring a head of what I call a data product, right? I would think if you guys broadly as in the data product kind of category. Is that different or mostly the same as someone running product somewhere else?

Yuval: Extremely hard hire. It can go wrong more than it can go right. I think I’ve been blessed to have a head of product that I’ve worked with before in the past. Maybe my advice to all people is never be the first head of product at a startup reporting directly to the CEO.

Brian: [laugh].

Yuval: And I kind of want to say that, right? Like, it’s a very, very hard position to be in unless you are extremely well-aligned. Because the founders usually come in with a vision that is theirs from day zero; hard to convince, hard to change. It’s a very hard position to be in, but you know, it’s on both sides. It’s on the founders and CEOs to sort of let go and say, “We now have someone who’s dedicating their entire day-to-day capacity to how we improve product UX, UI, functionality, so maybe my word shouldn’t be the final word anymore.” And then it’s up to the head of product to navigate through new territory and understanding what matters, what are the foundations that we’ve built, and then raise this product on that aren’t going to change.

Brian: Is there something specific about the nature of it—there’s, you know, data science, machine learning, analytics involved, this is an insights and intelligence product. Besides knowing something about analytics, or knowing some SQL, or knowing something about data, is there something particular that makes it that someone’s going to be a good data product manager? Is there a signal that you were looking for? I mean, obviously, you had previous work experience, but I’m curious what that delta is between a quote, “Plain,” or a regular product manager and this data product manager that stands out or key skills that you’re looking for there.

Yuval: Think user first, always. If they’re not thinking user first, they’re are enough people, you know, the hands-on developers, the coders, in some sense, the product arm is part of the engineering organization. And what they have to do is constantly take it back to the user. What does the user want? What’s the user looking for? How are they going to use the platform? What are they going to be thinking? You know, what’s going to hurt them? What’s going to make them smile?

Put yourself in the users' shoes constantly, no matter your background. If you come from the same background as your target audience, it’s good, but it’s also a risk. Deep Blue, the chess platform that won over Kasparov three decades ago, they tried to hire people that don’t know how to play chess as developers because they didn’t want them to be biased in their own way, prior ways of knowing how chess works. And so sometimes, ignorance is actually better. If you hire someone with a fresh perspective, set of eyes are going to be a lot more rigorous.

Brian: Yuval, this has been great to talk to you. Thank you so much. Where can people learn more? By the way, I’ll just say Akooda. It’s A-K-O-O-D-A dot C-O. Is that right?

Yuval: Yeah.

Brian: Okay, cool. And where can they find you [laugh]?

Yuval: I have a very long and unfriendly name, so took it down to the single letter: Y.

Brian: [laugh].

Yuval: [crosstalk 00:32:11] I answer all emails.

Brian: Subtractive design again, right?

Yuval: There you go.

Brian: So yeah, if you missed that, his email is Y—letter Y—at akooda dot co. So, it doesn’t get more easier than that. And I’m sure people can find you on LinkedIn. Are you active on Twitter or some other place more than that or is LinkedIn the best place to find you?

Yuval: LinkedIn is probably the best place. Yeah, I tweet in four languages, but English is only one of them. So.

Brian: Okay [laugh]. Excellent. Excellent. Well, I’ll put a link to the LinkedIn profile and to akooda.co in the show notes. Yuval, thanks for coming on the show and sharing your product journey with us.

Yuval: Thanks for having me, Brian. It’s been a blast. I love listening to Experiencing Data. Thank you so much for having me.