The Tanooki Talks Podcast, Ep. 4

On our last episode, we hinted at how long we've been doing this and Eric Dave, I've gone back, done the math. We've got about, you know, 65 to 70 years, depending on how you want to count it between the three of us in the space. So in that time, we have come across a whole lot of pitfalls. We've stumbled into them ourselves.

We've watched others tumble into them and you know, we've identified these things that people should pay attention to and you know, it's how we go about helping our founders as they're building out their products by, you know, showing and sharing all of the things that we've come across in the combined many, many years of working in tech.

So one of those that comes across a lot is what we've all kind of. Defaulted to calling the shiny tools problem, Eric, you want to give us a little definition of what the shiny tools problem is? Sure. And I think it's, it's a reflection of our mantra, which is, you know, from a tech perspective, when we're building the pieces that are fundamental to a product, to a piece of technology, we tend to be a bit boring.

And we do that on purpose. We want to use tools that are tried and true, that have stood the test of time, that are going to be things that people know in three years. And if you choose the latest technology and, you know, backend code or new framework for your JavaScript, It is entirely possible that that will fall out of favor in a few years, and no one will really know it and be able to work on it from there, and also that you'll end up with a number of different technologies in your stack without a real cohesion between them.

So we sort of dubbed this shiny tools pattern as a way for us to identify when something was being used just because it was fun or interesting or exciting and not necessarily the best choice for the product or company.

And, you know, maybe the place where the rubber meets the road around that a little bit, just in terms of even of what you're saying, Eric, and like choosing a platform development platform that will fall out of favor in some period of time, which means it's harder to hire for, which means more expensive to hire for, right?

And then also, you know, beyond that, even like, Becomes more expensive to maintain if like the, like, for example, we love rails because the community is so dynamic and strong and long term has such longevity, but I mean, I don't know, I'm trying to think of other like frameworks, but if that doesn't exist, that that actually costs the company that built on that platform more because you get some of that shared value from from the community of these things.

Right?

And I wonder, as we think about things like, you know, languages, when we think about things like platforms that we're building on and with, you know, a lot of these tend to be, if not developed explicitly for particular solutions, they kind of adapt over time for solutions. And you don't want to go, you know, mixing and matching between programming languages and, and, and the end result product that you're looking to build.

Right. I also think it's a question of premature optimization, right? At what point. Are you going for absolute blazing speed and performance, and are you doing that at the expense of the experience of the end user, your developer ergonomics, and the cost to the company up front? And as a completely absurd example, you're never going to write a website.

In assembly language, you might unroll a few loops of a HTTP server in that you might write a movie decoder in that, but those are the very tiny places where that level of, you know, bytecode optimization is going to make sense writing your website in an extremely performant language. Can take you 10 times as long as doing it in something like a framework like Ruby on Rails, where you have an expressive language, you have a existing framework with lots of community that's been contributing to it for over a decade.

That's not to say that's the one and only language, right? There's plenty of other ways that you can build a website, and today you can write in Node, you can write in Python. And any of those are going to have that same level of sort of right fit between the ease of developing in it. Shipping features that matter to your users and also being performant enough until you get to massive Facebook skill.

And then you can figure out how to deal with those problems. And you know, Facebook's famously on PHP and they figured out how to hack around that, you know, in quotes. So this also brings to mind, you know, we talk about the shiny tool and we talked a little bit last time about these kind of hype cycle products and tools.

And we hinted, you know, a little bit at like blockchain development in the previous episode. What, what, you know, what do we think about those things? Right. Where they may be a good fit, but maybe not. Well, I guess you know, one way to think about it is, you know, they're, they're, they're, I mean, we talk about these in terms of hype cycles sometimes.

So. The ones you mentioned there, Dan, that I think are currently pretty obvious. So AI is one of those today. Crypto was last season's or one of last season's, I suppose. At one point, mobile was that like just being on a mobile device. I mean, at one point, Web 2. 0 was right sharing you know, social things and people contributing back.

So and you know, another one funny one that comes to mind that's in a minor way is probably like the called the tinder swipable interface. Right? So to me, this is like almost the quintessential shiny tool, because at one point there, you know, there were how many startups existed that were we do recipes.

But with a swipe interface or how many, you know, how many of, you know, apps that you used, like, ended up with something that was like kind of harder to use because they just tried to use something that was like, you know, you, people were exploring the, the, the UX space around it. And, you know, maybe it's a good marketing tool to some extent.

Maybe someone on their team wanted to use that methodology because it was, would look good on their resume and they could talk about it later, but some reason or another, like. Things hit this hype cycle and people feel almost compelled for all kinds of reasons to include them in their product. And, you know, I mean, in many cases that that might be the game changer, that is the right move.

You know, a lot of times maybe it's not, and the real. Way to figure that out is just think about how, you know, like what's the real value that adding a swipe interface, you know, jokingly, but like, or having a mobile app instead of a website or incorporating the blockchain instead of just a database that has some, you know, transparency involved, right.

And, and thinking about how that relates to really the value that you're providing to people. And fundamentally that's where we come from, right. We're thinking about. Value to the end user empathy for the end user above all and if we can get there that we can understand what tools we need to build that rather than coming from the tool first, right?

If I'm and I'm guilty of this in my real life, right? I will buy myself a fancy mechanical keyboard to write my novel. No, I should just write my novel, right? The keyboard has nothing to do with it. It's not going to make me write it. We can be guilty of the same things with software, right? Working with tools that seem fun and exciting is one way to feel like you're continuing to grow and learn on the job, but it does really take the understanding of why, why are we building this in?

And I think as much as Dave and I were both extremely interested in the technology behind cryptocurrencies and the blockchain. We were also resistant to building it in for clients unless it really. Was essential and the only way to solve that problem. And for so many of the folks that we work with, a database with a central server made much more sense for their customers, for them as a company.

And that was ultimately our recommendation. So is there any kind of, you know, if I'm coming from this as a founder. How do I tell, especially if I'm a non technical founder, how do I tell hype from help? How, how do I examine this? So I think there's two axes that we want to measure this on. One is, you know, how much will this help my customers and how much will this help my team?

And you need to answer that question now. And in a year and in three years, and if you can do that, if you can talk to your lead engineer and they're saying, Hey, I really want to use go for this part of our service. If you can say how will that help our customers and they can say the system is going to be able to deliver 300 requests for every one that we can do right now, but also it takes about 25 seconds and we're going to get that down to 2 seconds for this one thing where we're going to use this, you're hearing some of the things that are really great.

This person is suggesting the technology because it's going to make a big difference for the company and for the customer. And they're also limiting the scope. They're not saying we're going to rewrite everything because I heard that Amazon said you have to deliver a page in under 250 milliseconds or your customer goes away.

Right? That's a factoid you can spew that's about e commerce in particular. That's not true for the whole world, right? Faster isn't always necessary for every single webpage ever. Most things are good enough. You don't need blazing speed. So listening for, are they talking about the end user? Are they figuring out how this helps them?

And then how will this help our company? Is this something we can hire for? Are there other humans who know how to do this? But you, are there people who will still remember this technology in three years? Does it have a growing community and will it be incredibly expensive to hire for this? And this can cut both ways, you know, four square used Scala.

They were one of the largest shops to do so. That meant that they were selecting for people who were willing to learn that sort of esoteric flavor of Java. It was a interesting litmus test because it helped them hire some of the best engineers, but it also certainly made it a smaller pool for them to pick from.

That is really, yeah. It's interesting to think about that, the future scalability of hiring as kind of a an impact point on this, what do we think about using some of these tools perhaps in not necessarily in private, but internally, right. Using them as testing grounds. If people are, you know, if you're looking to hire and want to, you know, you always want to hire people that.

Want to continue to learn that's, you know, a core tenant of who we hire. That's just a core tenant of, you know, what a good hire is. What do we think about using that building internal tools, using some of these shiny tools, perhaps. Well, the example Eric used was an interesting one, right? Where it was the, this kind of esoteric programming language is actually like drew a bunch of smart people who wanted to work on, on it and learn, learn in that way.

So, so I mean, there's certainly a call, like a marketing component maybe from that you know, I think it's, it's also interesting if you look at people's. And there's some folks that, you know, I mean, it's, I mean, funny, like working where we work, like we've probably touched each one of these things in some way.

And, and just kind of seeing how have, you know, what were the roles that people had in the past and. Were they were they working on you know, more often these kind of like trendy sorts of things or, or, or how did they have like more direct business experience around, around things, like, were they bouncing around?

Jobs in, in a way that like, you know, like, well, you know, the, the set of people who now work at an AI company that previously worked at a crypto company that shortly before that were at outta something else. You know, like, like you know, it's, I mean, not saying it's good or bad, but it's kind, it's, it's certainly shaped someone's perspective on these things.

And it's, it's probably worth. You know, considering in that way, but in terms of, you know, like, and so that might draw more people like, like that, you know, whereas something a little bit more, I don't call it conservative, you know, you might, you might end up that might end up being a different sort of talent pool that you end up drawing towards you also think that.

You don't have to poison the well of your main product in order to get to play with these technologies. You know, we built our own crypto powered press release system in order to experiment with the technology to see if that made sense. There was a thesis there that would have been interesting.

Multiple parties want to participate and publish, anyone can listen, and there could be a currency. Right. It makes sense on paper. Let's try it. Let's learn from it so that when our client comes and says, Hey, we want to do this, we can say, you know, you can, but here's some of the pitfalls. And here's what we learned when we played with it.

Absolutely. With AI right now, we're building internal tools so that we know exactly what to do and not to do when putting together knowledge plus tooling to equal a product. There's going to be. Things that you can't possibly bring to a final product experience without experimenting, but we're not going to change everything and say, we are an AI company that does all AI development.

We're going to get good at it and focus at it for clients who need it and for products where it doesn't make sense. We're not going to mention it. So I wasn't going to directly address the 900 pound gorilla in the room, but Eric called it out. So is AI one of these shiny tools is the LLM is the modeling like all of this?

Are we living through another cycle with another shiny tool?

I mean, it's it's certainly a tool. Yeah, it seems it's trying at the shiny and shiny. So yeah, I guess that that probably fits. You know, and and so I think all the same logic applies, right? So as we've been. Like Eric, Eric said, the experimenting with these tools, you know, we, we did that in the crypto space and with our co pilot project, we've got, you know, our Tanuki co pilot kind of PM tool to some extent is where we're applying that as well which we've talked about, I guess, a couple of times on here.

But you know, I think that the way that the. It's, these are so much fun. It's a place that you want to spend a lot of time. And I think one of the things that we have found interesting is balancing the, how do you, how much time do you spend exploring and those things? And we're like, how do you efficiently, like, I mean, what we end up doing a lot of times is when we have some free developer time on from our full time team, we'll focus kind of folks in that area with a direct plan with a goal in mind to really try to, you know, like, what are we trying to learn about this thing and.

What might be useful for us, right? So there's kind of this balance that we consider there. And then, you know, it's always a struggle of, well, who has time and how can we do that in an efficient way? And I think that balance is actually kind of valuable because we spent too much time. I think we'd go down rabbit holes that would really help us a lot.

But by using this as like a capacity filler, to some extent it keeps people like excited to have like something new that comes up and then also you know, just kind of keeps us on our toes and gives us some space to like, think about it without having to rush to, you know, okay, what's the next feature we have to work on?

Because we have, you know, we have a full time person who's, you know, literally burning resources every day. They're not working on this, right? So from my perspective, I completely agree. We're in the, yes, this is the shiny tool. Everyone wants to build it in. And not every product needs a chat bot. But to me, I think there's a big difference between crypto and this.

Crypto was a tool which has a lot of Possibility, but not a huge amount of direct applicability to most people's lives into most products or companies, at least not today, the jump from, Hey, I can make a distributed ledger to, I'm going to build it into something is fairly technical and difficult for a long game playoff that won't work until there's mass adoption of everyone having a crypto wallet, whereas AI is almost completely inverse.

Integrating is incredibly easy. Developers will sit down, take 2 3 days and say, okay, now this reads in information from here, takes the user's input and we get an answer. Isn't that neat? Now what do we want to use it for? So I think there's going to be a much faster experimentation cycle. And I also think there's a lot more applicability.

You know, McKinsey just announced today that they're using an LLM powered by their own corpus of documents for each client to have an internal. Product whisperer that can give advice, help right and have that deep knowledge across the organization. And there's an org that has massive retained knowledge across years and regimes at other organizations perfectly positioned to sort of reuse that knowledge.

Great use of AI. Is it the shiny tool of 2023? Will we all look back and remember, Hey, that was the moment when everyone did that? I believe that's true, but I also think it will be. More set in the tone of that's when this all started and it's easy to forget, right? GPT 3 is just this year, right? It's not like this has been around for a long time and the huge leap that we have from, you know, we could kind of generate an image and maybe some text last year to it's available for everyone, cheap and easy to build in.

We're still just at the beginning.

Dave, I think that you had mentioned in the kind of list of shiny tools earlier on the, you know, web 2. 0 was a shiny tool at some point. I think that really ties into what Eric's talking here about AI and that it was when things began as opposed to just being a shiny tool, right? This is, you know, a shift in how something is used.

It's sort of like getting a Tool added to the toolbox rather than just being like, Oh, now all I have is hammers. I'm just going to hammer everything.

Yeah, I think I, I hope, I hope that's true. And I hope we maybe learn lessons from, from how that kind of has played out in some sense. Right. I think there's a lot of you know, good things that came from the web 2. And, you know, some challenges as well. And I mean, this is probably an even bigger.

Has an even wider range of of pros and cons. So you know, that that's maybe 11 way to look at it. But, you know, if you look at it from a you know, a financial perspective, like Facebook is how big of a company now? You know, and like that so what's the, I mean, I'm sure like this is the classic VC thing.

Right. But it's like, okay, well, what's the Facebook of this you know, this thing. Right. That, that'll be an interesting yeah. And is that, is that open AI? Maybe but what seems to be interesting with those is like what Google was like, I don't like the 12th search engine or something. It wasn't like the first.

And so, you know, I, I've heard a bunch of takes I've liked on this where it's like, not like Apple does it this way. It's like, not necessarily the first mover who always wins. It's, it's kind of like the third or fourth person who's kind of seen how it's done and was able to come in in a different way, like, like knowing what, like, was hard to learn.

So. That's, that's one thing I'm kind of interested in seeing is like, what kind of, you know, what's the next couple waves of these things, right? Because it's clearly not going to end tomorrow.

I do want to bring it back to some core technology to rather than just thinking about AI and product, you know, what about the tools that you're building with? We were resistant to JavaScript frameworks for a very long time for the same reason, right? If we have to go back to some old code and it's using Angular 1.

3, you know, that was absolutely seen as the best front end framework for quite a while. And now, touching a code base that has it is like finding the crusty old person who remembers exactly how it was done and hasn't already moved on in their career. So, We eventually started experimenting with React. We tried it in a couple internal products, and then tried it as a component in certain places for applications where it worked.

And now, I would say, it's in most of our applications, and in certain applications it's the predominant way we're doing the front end. That's been a gradual change. And it's also been informed by the fact that React Native is so good and has been so good for so long. Developing mobile applications, so some of this is just about taking your time and waiting to see, you know, has this technology has this bad burned in a little bit and then riding along with the community absorbing all that knowledge rather than being on the absolute leading front edge.

If you're building a company that. Doesn't need to be at the forefront of tech. It just needs to deliver its service. Well, being on the bleeding edge of tech is probably the wrong decision. Not always, and you can consider pros and cons, but certainly for the fundamental tools you're building with, you want to use something that's been around rather than what's new and exciting.

Yeah. Where are you adding innovation? Is it in the, you know, your, your internal development stuff or is it like what you're building for your customers? So yeah, that's a good point. Yeah. And that reflects, you know, very squarely with how we approach engagements, right? The innovation is in. The founder's history with the product, with the service they're providing, it's their insights, technology, technology, and we can manipulate that to serve a whole bunch of needs, whether that's using something that's new or something that has burned in a little bit, I think that's a good way to look at this is.

Look at the mix, find the thing that is right for the solution you're trying to provide for your users and always keep them in mind. Eric, you spoke earlier about, you know, we're empathetic for the user. And I think that that's, you know. Occasionally a rare thing and a good thing to kind of keep in mind as a founder is coming across new tools, whether that is blockchain or LLMs or whatever is around the corner and there's the other thing, right?

There's always something around the corner. And I think using that as a frame, especially for non technical founders, it gives you a chance to ask the people who are building your tech in a non threatening way, right? You're not challenging them on what they're building. You're saying, how does it, how does this add value for end user?

How does it add value for the company? Gives them a chance to reflect and go, well, maybe it does. Maybe it doesn't, and they can defend it and you can listen to that. With an ear towards is that true or is that what they would like to build it in and why what are those reasons because maybe those reasons matter to maybe they've got three people who are really great at developing that and as a team, they're going to blaze forward fast.

Great. That can be a good answer, but you should understand that that's your answer and that it might come with other costs.

Great. Well, I think that kind of wraps it on shiny tools. I think it's super helpful, a wonderful way to look at framing this kind of pitfall that we've seen a lot of people come across and really, you know, giving some guidance on how to frame how to think as you move forward in developing your product.

And you know, making sure, like we said, always keep the user and their experience in the forefront of your mind. And you'll always come out ahead by doing that.