← Software Engineering Daily
Software Engineering Daily
Empowering Cross-Functional Product Teams with Tobias Dunn-Krahn and Doug Peete
00:46:28
Modern software teams typically rely on a patchwork of tools to manage planning, development, feature rollout, and post-release analysis. This fragmentation is a known challenge that can create friction and slow down software development iteration.
Loading summary
Transcript57 lines
- [00:01]
A
Modern software teams typically rely on a patchwork of tools to manage planning, development, feature rollout and post release analysis. This fragmentation is a known challenge that can create friction and slow down software development iteration. It's especially problematic for cross functional teams where differences in roles, expertise and work culture can further complicate collaboration. There is growing consensus that successful software product development requires continuous collaboration across functions including design, engineering and operations. Tobias Dan Kron is the CTO and Doug Peet is the Chief Product Officer of atano, which is a software development lifecycle platform focused on cross functional teams. They join the podcast with Kevin Ball to talk about the challenges of modern product development, the importance of low friction ux, the role of AI and product tooling, and how to unify product design, engineering and operations in a single workflow. Kevin Ball, or K. Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through latent space. Check out the show notes to follow K. Ball on Twitter or LinkedIn or visit his website K Ball LLC.
- [01:33]
B
Foreign.
- [01:37]
C
Hey guys, welcome to the show.
- [01:39]
B
Hello.
- [01:40]
D
Hi there.
- [01:41]
C
All right, let's get started with a little bit about you two and what kind of led into Atono. So maybe a quick intro and then how that has evolved into what Atono is becoming. Let's start with you Tobias.
- [01:54]
D
Okay. Hi everyone, my name's Tobias Duncron. I am a CTO and co founder of atono. I started out in the development sphere. Over the course of my career in the past 25, 30 years, that role evolved into managerial roles. I did get quite involved in the operational side of things over time and then actually ended up doing quite a bit in terms of product ownership and product strategy. So a pretty good swath of the various roles, not all the roles that are involved in making software, but a good little sampler there. And I've worked at companies that are very small, just a few people, all the way up to large public companies and a lot of that experience actually informs how we've decided to build and the way that we built Atono. But before we get too detailed on that, I'll pass it over to Doug.
- [02:47]
B
Hi, my name is Doug and I'm Chief Product Officer at Atono. Like Tobias, I come from the 1900s, been building and designing software for a long time. I'm a geek at heart, started out in the engineering world, but I've always gravitated More towards customer facing type of technical roles, consulting technical pre sales, but for the last 25 years product management. So typically forming with Tobias, a dynamic duo, building out strategy, building out roadmaps, building out products, getting all the way down to the feature levels that built together well.
- [03:26]
C
And I guess that makes a lot of sense then that you're now building a tool targeted at that audience of how do you think about product management? And I think this is an area that's ripe for some disruption. There's some long standing players. I know there's a few different folks who are trying to disrupt it. So maybe talk a little bit about Atono and what your angle is into this area and then we can dive into the details.
- [03:48]
D
Sounds good. So Atono does do a lot of things that you might be familiar with from those long standing tools and some of the up and coming tools for managing the software development life cycle. One way in which Atono is different is that we put an emphasis on first of all, high quality user stories and we think that they're worthy investment for a number of reasons, which I'll get to in time in excess of just the usual value of having high quality user stories where product people can talk to the implementers of those stories stories. So we acknowledge that when a story is complete, deployed, shipped to production, that's not the end of the life cycle. So OTONO is built to support cross functional teams that not only build that software, but run it. So we have integrated features such as feature flags where you can natively control the rollout of a feature right from within the story, right from where you wrote that story. In addition to that, teams want to know how their product investments are performing. So we have a feature engagement module which allows you to see what are your most used features, how the uptake of a particular feature or user story that you have implemented is going, if it's performing to your expectations, if customers are adopting it, and so on. We have a lot of ambition to go further down that road of not just building software, but running software. But hopefully that gives you a basic flavor of the direction we're headed.
- [05:25]
C
Yeah, so a few different things that I'd love to dig in there, but let's maybe start with something that I think is interesting, which it sounds like you're kind of targeting multiple audiences here. Right. You're talking about things that often are sort of more in development land around feature flags and integration and running software. You're also talking about the metrics and things that PMs care a lot about so one thing I've seen in this space is most of the tools out there are targeted to an audience. PMs love Jira. I have yet to encounter an engineer who does.
- [05:57]
D
I didn't know we were allowed to say that on this podcast.
- [06:00]
C
Oh, I would dive straight in. Right. And I'll flip it around. A lot of engineers really like tools like linear and I found those to be less intuitive sometimes to non technical audiences. So I'm kind of curious how you think about who are the primary Personas that you're targeting this at.
- [06:16]
D
Yeah, and without like going too far back in history, I do see this as a fairly straightforward evolution. If you look back to the pre cloud era or the pre Agile era, you had software development teams that were, say, separate from testing teams very early on. Those were combined so that they had mutual goals. And moving forward more into the cloud era, same thing happened with operations teams where you had embedded operations engineers that were specialized in actually running and operating the software. But it was a team concern, it was made a team concern. So all of the trade offs that you had to do at every level had to be considered by the team. And in our careers we've seen that to be very functional. It allows for even larger companies that have scaled up to still act like a bunch of little startups and all, each team being fully capable of shipping an increment of software and delivering value to customers. So we want to support those teams, those cross functional teams. And I would expand those roles that I mentioned to include product owners, designers, software engineers, testers, operations engineers, and even customer support engineers and beyond. So having all of those concerns be amalgamated into a single team makes for like a very functional unit that allows you to serve your customers. And we think that the existing tooling out there is not like you say, it's very splintered. Each of those roles probably have their own tools. We don't necessarily have the ambition to cover all aspects of all of those roles, but centering on user stories and the expression of what is valuable to a customer and moving out from there, we think is a good strategy.
- [08:10]
B
I think it's interesting, Kevin, that you talked about that spectrum of what appeals to PMs versus what appeals to engineers. The way the product's been built out, I would say that it actually provides a lean towards the engineers, but that's not necessarily who it solely caters to. I mean, we put emphasis in saying cross functional product teams because we believe it's the whole team. It's just we feel like the engineers haven't had as solid of a voice in how products get built. I'm not necessarily the most eloquent at phrasing things and there's been this idea in the back of my head around that empowerment that's always troubled me. And a couple years ago I was introduced to some of the work of Marty Kagan and he talks a lot about the empowerment of product teams. And when we look at look at the consistency of most product teams, you have pm, a product owner, designer, but a bunch of engineers, like look at an organization, there's usually multiples or orders of magnitude more engineers than there are PMs. And it's a shame that we don't do a better job of empowering these engineers to be part of the design process, part of the creation of what it is. You know, we treat them like mercenaries often. And so when we look at how Atono leans, part of its lean is to try and address that disparity in representation.
- [09:40]
C
Let's dive into that concept because I think that's something that I've seen it show up in a number of different ways. I've seen it showed up with design, right, where you'll have a whole decision making process and then pull in designers towards the end. And I sometimes hear this described as like to put on their design fairy dust, right? Make it look pretty, where a good process integrates design thinking and user research and that sort of things from the front. Similarly, as you're highlighting engineering, sometimes it's like, okay, there's this whole decision process and then how do you build it? So what goes into a tool that can facilitate that more integrated and cross functional kind of feedback loop across all these different parts of the process.
- [10:19]
D
So Atono workflows are customizable to some extent. There are workflow step categories that are not customizable so that we can provide things like accurate cycle time or predicted done dates and so on. So you can support a number of different workflow styles. But out of the box, Atono has a story refinement workflow where stories are born and that includes a design workflow before a story goes to a team for sizing. So in our opinion, in fashion, we believe that stories can't be accurately sized without a design. So the design is pushed further to the front of the process by default. And we like to see that as a gray area, not like a series of gates that you have to pass. You don't have to have a fully baked design before engineers see anything that's not functional, not agile, however small Variations in the design can generate drastically different levels of work. So if you want to have a predictable process, you have to have that conversation happening early on. And that's our recommended approach if you really don't like that. If you want to take the fairy dust approach, you could customize workflow to do that, but that wouldn't be our recommendation.
- [11:39]
B
Just piling on that. So first of all, Kevin, thank you for using the term sprinkle pixie dust. That sounds much better than lipstick on a pig, which is what we typically hear. One thing I would pile on with what Tobias was talking about is that we treat stories differently in terms of the amount of structure that they have, all the way down to even acceptance criteria, being first class citizens. So if we're going to get geeky, it's not just some text field or markdown field with a bulleted list in it or a numbered list in it. ACs are actually objects and that means you can do special things with them. You can move them around, you can attach comments with them. The comments stay attached with them as you move them around. You could have ACs that are suggested and known to not necessarily be canon. So people aren't afraid, like a lot of times developers are afraid to touch the story. They think it's some sacred document. But by having ACs be something where they can have a state, then we can allow people to suggest ACs and then have various approval processes, type concepts. It also unlocks some of the behaviors that device biases hinted at around feature engagement and being able to tie the metrics all the way down to specific ACs that are getting exercised in the different environments. So there's some pretty unique things I think that we unlock across the spectrum by treating acceptance criteria as first class citizens. And some of that spectrum is on that design side and helping pull in UX and engineers. Anybody else who's part of the cross functional product team to participate in the story in that earlier mechanism.
- [13:24]
C
That's super interesting because I think to your point, right, like acceptance criteria is one of the things that I think as an industry we've sort of evolved to. If you want to actually verify that the thing that happened is what you wanted, you need some sort of structured acceptance criteria. But a lot of times that just means here's a text blob, make sure this is true, make sure this is true. So how does that structure that you're adding there, it lets you create a life cycle, as you mentioned. How does that integrate to the other parts of the process? How do you integrate that into your code for that automatic testing. What does that all look like?
- [13:57]
D
A very practical application of that. I don't want to go by without mentioning this because it's something that's irritated me for years, which is when you reference an acceptance criterion in say chat, Slack or whatever, you're usually doing it by number. So like AC1B I, your user story changes, that reference is no longer valid. Somebody doesn't know what you're talking about. So just from a very practical perspective, any ac, you can just grab a link to it, put it in chat. When the recipient clicks on that, it brings it up, flashes which AC they're referring to. And if the story changes, you're still going to get a reference to that ac. So it's handy. Just for really practical things like that, where we're headed with that. Well, first of all, just to echo what Doug was saying, you can attribute product usage to individual ACs. So if you had a set of ACs, for example, in our demo application, there's a number of ways that you can share something. So you can share via individual social media channels, or by email or by a link or something like that. As users use the product that you're building, select amongst those options, you can attribute that usage back to those ACs and see which parts of your story are getting the most uptake from customers. So it allows you to do some like pretty sophisticated product analytics. Where we're headed with that is enhancing what has to be done for each of those ACs in each of the workflow steps. So you can imagine within the design phase, making sure as a Checklist that all ACs are covered by a design, similarly for development, similarly for testing, or similarly for product review. And then when you get to having a deployed product, which of those ACs are actually being used in production, you can evaluate how well you've done in terms of making the most valuable story possible. So it unlocks a lot of different possibilities.
- [15:53]
C
Yeah, that's really interesting. And thinking about them, yeah, they're an entity, they have an ID that you can permanently link to that you can reference back to when you're product user analytics. Very interesting. Are they still like distinct to a story? Can you share across stories or there any other sort of interesting dynamics that come by making this a standalone entity?
- [16:13]
D
They are not shared across stories, but it does unlock the possibility of having automation be able to split stories for you. So if you need to take a story and make it smaller, that is something that can be done in an automated Fashion, because these are top level objects. And one of the things that we are playing around with right now in terms of features that are coming out soon is having AI suggest to you splits. So like first of all, does a story meet invest criteria? If it's not quite getting there on the small aspect of that criteria, suggest a split in terms of how well it does on that. That's tbd. It is surprising to me. Honestly, I'm quite an AI skeptic, but some of the testing that we've seen so far is promising. I believe there will always be a human fixing up stuff, but it's certainly a labor saving device to have a reasonable suggested split. Maybe you have to tidy up each of the parts, but in any case, that type of automation is facilitated by having acceptance criteria be first class objects.
- [17:19]
B
I would also pile on that in terms of being able to to interact with third party systems as well as AI is greatly facilitated by having it be structured. Because I'm not just relying on diffs like if you want to say help me make my story better, suggest some ACs, not just suggest decomposition, but all the different things that you might want some help with. When it's in that structured format, we can literally make specific recommendations. You can step through, approve, reject, do all those other kinds of things as opposed to coming back to saying I'm going to diff this text blob and this text blob and then let you kind of figure out what you want to keep, not keep. So it unlocks a lot of things so far, and we're finding many more behaviors as we go that it helps unlock totally well.
- [18:11]
C
And I'm deep in the AI coding world and one of the most valuable things you can do to unlock that being actually useful, rather than pushing you off in weird directions, is having something that's a formal validation that you could do a validation in the loop of like, oh, you went off and did something. Can we check it against unit tests or typing or acceptance criteria?
- [18:31]
D
Yeah, exactly. And just to be clear, we've also put a lot of effort into the UX of creating stories. So from the user's point of view, as they're writing a story, it just looks like they're creating a list. Like it looks like a free text field. So you can just blast through and create tons of ACs as if it was a free text field. It just happens that under the covers these are structured objects that you can drag around and tag and manipulate and so on. So we definitely didn't want to compromise on like a lot of structure at the expense of a poorer user experience.
- [19:03]
B
If it's not clear from the geeky passion coming through. We're obviously big believers in stories and story quality and we oftentimes as we're working either within our organization or sometimes we help out other organizations with their challenges around software project management. We always come back to invest. Are you familiar with the Invest mnemonic?
- [19:29]
C
It's probably worth going through it quickly for anybody listening.
- [19:32]
B
So Invest is a mnemonic and it speaks to the attributes of well written stories. I don't know if going through it every one of the bullets is this helpful or not, but for listeners, I highly suggest you go out there and look at the different content that's out there on it. But it greatly influences where we are putting features in and how we're building the story interactions and the things that we're trying to make sure that the product simplifies. There's a few different ones in there that I'm a big proponent of. The N in investing is negotiable. Trying to make sure that you don't over specify what it is that the story should do and how to do it. Like again, let's unlock the design powers of everybody to make sure that we can figure out what the best way is to solve a problem. And that has a whole, I think, interesting bit of philosophy around it. But there's the other two I run into that I think are quite interesting. Is the V is valuable? How do I deliver incremental value? Like that's Tobias. And my role primarily is is how do we get valuable stuff to our customers and what the definition is of that value versus the S, which is how do you keep things small? When you work on smaller things, you get better estimates, they're easier to deliver, you can get feedback faster. Like there's so much value in keeping things small. And so back and forth between playing with that value versus the size of something, that's where a lot of the tough decisions get made. So when I hear Tobias talking about unlocking things like the decomposition of stories, we're big fans of decomposition and emphasizing the small and getting small valuable increments to our customers. So what are the tools that support that or what are the features in our own product that support it? It ends up being kind of meta because we're building products to build products.
- [21:29]
D
So.
- [21:30]
B
But yes, when we think about how we build a tono, you know, it often comes back to invest the decisions that we make.
- [21:35]
D
Yeah. Any friction you can remove in that process is good. There's resistance to decomposition pretty much across every role. There are reasons to do bigger chunks of work in terms of like efficiency or tooling or just the overhead of splitting out the story shipping two different increments. So you get resistance pretty much across the board. I don't think anyone thinks it's like a bad idea in general. It's just can be a lot of paperwork. So anything we can do to reduce that friction we will do. I do think it's interesting on the design side. I think that developer tooling in terms of like continuous deployment and just general CI CD pipelines have been improved over the years so that there's less resistance for engineers to ship small increments has unlocked by the cloud era and all of the tooling that's been built up around that. I do think that the design side suffers a little bit. It is quite laborious to make independent designs for each of the small stories that would comprise an epic or even a larger theme. So I often feel guilty about asking designers to like come up with individual designs for each of the decomposed stories. I don't think that's going to be a problem that we're going to set out to solve necessarily, but just a shout out to anyone out there building design tools. A way of splitting designs would be in an automated fashion would be pretty awesome.
- [23:05]
B
We'd like to party with you. Reach out to us.
- [23:08]
C
Yeah, I love that. Well and I like that as sort of an organizing framework of like how do you make it easier to decompose and recombine and do all of those different pieces?
- [23:19]
B
Yeah. I would say as a product management leader and having worked with hundreds of product managers over the years, it's not just the UX folks that are taking the moonshots. I find it's pretty common for PMs to not shoot for the M in MVP minimum viable products. Like there's just this tendency to have this. What is thought to be a critical mass of features that in the end you have to challenge folks on saying isn't there value to just this or just that? And that constantly have to work with product managers and product owners in order to help them get there. So there's the philosophical elements of how do you deliver valuable increments and what is value and really pushing each other to make sure that you get there. And the engineering team's doing that as well and then providing the tools to make it so that it's just second nature. It's easy to do. Let's remove the overhead. Let's make it easy to keep these acceptance criteria, move these to another story, and that's where tonal comes in to help streamline that process.
- [24:25]
D
Another thing that is kind of rolling around in my head is that one of the major values of splitting stories is so that they're independently shippable. But once they're shipped, all of your stories can be quite fragmented. So we also have ambitions for post shipping, recombining stories that were split up for the purposes of independent shipping. So just as slightly more concrete example, you would have an EPIC that was decomposed into 10 stories. Perhaps not all 10 stories got shipped. This is agile after all. Maybe we decide that three of them are too expensive or don't provide enough value or just run out of time, whatever. So seven of those stories make it across the line and into customers hands at that point, for purposes of archeology, it could be more difficult to find the information that you need on that if it's split across seven stories. So recombining those into what they were before they were split could have some value. And again we can approach that in an automated fashion based on the way that we've modeled user stories. So same thing for collecting usage data perhaps. Like if you are looking at usage data across seven different related stories is maybe not as convenient as a combined story. So. So I think there's a whole other side of the deployment universe that's sort of greenfield and we're going to explore that.
- [25:48]
C
That is interesting. So let's maybe talk then about some of the tooling that you provide post deployment or after deployment, which is I think a differentiating factor here. A lot of these tools don't worry about that. You ship it and you're done. Maybe at best you have like a tag back for tracking or something like that. So you've talked about analytics, but you also mentioned something about feature flags and rollout stuff. So what are you doing there and how do you think about that? That and its connection to stories?
- [26:14]
D
Yeah, so I'll just take you through a typical workflow. When a product owner has authored a story, they have the ability to say add a feature flag to this story. So that means that I want to control the deployment of this story. Maybe I want to, you know, release it across my stages in individually. Maybe I want to roll it out geographically or to just specific customers. Like I have an early access program. So I can say that this story is going to be flagged. And our flagging system is based on open Feature, which is an open source flagging framework, which is a couple of advantages. First, for customers, it's makes it easy to swap in and out flag providers. So if you decide like Kotono flags, you want to use some competitor or you, you want to roll your own or something like that, it makes it much easier to do that. So most feature flag products now adhere to the OpenFeature standard. And the second advantage of that is that OpenFeature provides wrappers for just every single language or framework under the sun. So that's a nice freebie for us. In any case, once a product owner has indicated that a particular story is to be flagged, there's a reminder that gets put into the story itself. So when developers see the story, they'll see, oh, this one requires a feature flag. That reminder includes link to some sample code. If they haven't done it before, they can see how to integrate feature flags into the feature. And at that point, right from the story, you can start flagging the story on and off. So let's say it's completed and it's in the dev environment, you can start turning it on for individual dev instances, or you can turn it on for the dev environment in general. So I think it's fairly standard feature flagging semantics. I think the main thing is it's just very convenient. Convenient to have reference for exactly what functionality you're turning on and off from the place you're doing also democratizes flags. So in some environments you would have product owners having exclusive access to turning on and off flags. In other environments it's the developer's responsibility. In some cases it's the operational, it's an operations engineer responsibility. So we do provide a permissioning model that allows you to lock that down if you want to, but if you want to have it be a team, responsibility can be open to the team that implemented the feature. So in any case, all of those roles are able to see the flag status very easily. So they can see per environment or per slice. And when I say slice, I mean a combination of location, customer environment, you know, however complicated you want to make your rollouts, you can see exactly where that flag is on or off. And then another topic that I think is relevant is feature flags as technical debt. So making it a team responsibility to not continuously accumulate feature flags. So we put a lot of effort into showing the status of a feature flag, which is a little bit complicated because you have the configured status, which is, you know, your indication of where you want the flag to be on or off in different slices. But there's also the runtime status, meaning which of these environments are actually making flag requests. And so that gives you an idea of like, what's happening in real life. So between those two data sets of like what's happening in real life and what you've configured the flag to do, you can make decisions about whether or not you can remove a feature flag. For example, if, if the flag has a mixed evaluation status, like, you know, it's been on and off in different environments in the past, but you can see that all current flag evaluations are coming in only for prod. And we're always returning an on status. We know that that flag is safe to remove. So surfacing that data, I think is really important to be able to confidently remove feature flags over time and not have them just constantly expand your test matrix with like, you know, these flags on, these flags off, which can be extremely cumbersome over time.
- [30:38]
C
Yeah, well, and you anticipated a question I was going to have because I think feature flag systems have a tendency that a lot of systems have of. They just accumulate over time and it gets slower and slower. And so yeah, I was wondering both. Yeah. How you thought about it. But then also you had mentioned before some sorts of automation around story splitting and generation. Like is there some sort of automatic detection and not only elevating it, but even creating like, hey, this is ready to be cleaned up. Let's prioritize this. Something along those lines.
- [31:10]
D
Yeah, no automation for that yet. It is. You can go to a feature flag list page and sort by various criteria and make decisions about that. But yeah, certainly something that's on our radar.
- [31:20]
B
I would mention also that a lot of the ramifications of this stuff is on the cultural side. So unpacking it, but kind of in reverse order on the cleanup of feature flags. The added visibility that folks have does encourage the hygiene that we all want and hope for. I think you mentioned it earlier as tools tend towards the more specialized and you know, you've got feature management tools out there that can do all kinds of crazy different rollout deployments in automated fashion. But when it comes down to the real basics around why do we use feature flags? We want to reduce risk and we want to get increments out faster. And so really optimizing on that comes back to the democratization that Tobias is talking about where I need to make sure that that's not in the hands of a PM who may be a stingy about a feature flag because they know they're going to have to pay for the removal later or some of the other weird things that we run into that are cultural in some of the companies that we worked at. You need a feature flag. You should be able to make a feature flag. That feature flag should be visible to all that. The status of that feature being visible helps encourage hygiene, but it also helps keep the whole product team feeling like they know where their code went and what it's doing and is it being exercised. There's another atono centric bit with this, is that there's also announcements that go out through the chat integrations so that folks can also. You don't have to go to the story to see it. You know, if you're involved in any of the stories related or, sorry, the chats related to the stories, it announces itself as there are changes to the different slices that you're putting in for feature flag evaluation. So just that sense of like, I am part of this bigger thing is brought to the entire product team as opposed to the folks that can just get to the feature management tool. That's something that I've heard quite a bit, is that as the feature management tools have gotten more complex and more specialized, they've gotten more expensive. And so I was talking with a company, they have 400 developers, they can only afford 20 licenses for the feature management tool. Like, that's crazy. This is something that actually is reducing risk and yet you can only put it in the hands of 20 out of 400 developers. You know, like, that's not good. So it's just built in. It's just part of the product. There's no additional licensing. We believe it's a fundamental thing. We believe it's so fundamental that that's how it needs to be.
- [34:03]
D
Yeah, I think it just fits into the free. The theme of removing friction. You don't want to have any friction or you want to have minimal friction in using something that's like you say reduces risk, allows for healthy software practices. You don't want to put up a paywall in front of that.
- [34:19]
C
I'd love to dig into something that I feel like I've heard pieces of a theme across both of you talking about, which is the connection between sort of product development philosophy and the tool you're building to enable things. You've talked about how you. You obviously are inspired by different pieces. You think things work best in different areas. I think the tool is incorporating some of that. But to what extent is there an education piece? How does that connect to the tooling? How do you think about that sort of interplay between this is how we do things. Our culture, our approach, our processes. And this is the tool that we're using.
- [34:57]
D
We try to build in an opinionated fashion. As I mentioned earlier with regards to workflow, if you use the product just out of the box, you will be guided to our opinion of what the best workflow is. So that manifests itself all over the product in number of cases where, you know, it really is just opinion. We do allow for customization to. For our product to be used in within organizations that just have different cultures or just different opinions on the way things should be done. But generally speaking, the path of least resistance in the product will guide you to what we think is optimal way. That being said, of course, you do need to educate people. So there's a whole, whole slew of publications that we have, starting with our help documentations integrated very closely into the product. So when I mentioned earlier about having a dialog pop up and give you a code snippet if you want it, that links into our documentation on like, okay, why use feature flags like, back up a little bit. There's also quite a bit of blogging that goes on in terms of like the way that we see things philosophically and, you know, why we have made certain choices. So how we try and get out the word along those lines. But this is actually Doug's purview, so I should probably seed the floor. Sure. Anything you want to talk about in terms of. Yeah, articulating best practices on the product side?
- [36:20]
B
Yeah, I mean, there's a little bit of a story behind the story in terms of us saying, you know, opinionated this and that's why the product works that way. I think we've had an interesting evolution in terms of the different sort of compute and delivery models that we've been able to see. We took a company from a here's the software on a dvd. Go install it on your servers to hey, we'll host it for you.
- [36:45]
D
Doug, you should never mention that we're from the DVD era.
- [36:49]
B
I said we're from the 1900s.
- [36:51]
C
I mean, I still remember wiring up servers in order to test hardware. So like, I'm in your vintage. Though many of the folks listening, listening may not. All right, so let's talk slightly different in some ways more cultural zeitgeisty topic. How do you see product development right now shifting with all of these different AI tools and advances? You mentioned you're building some AI into the product. I know it's definitely changing the way that I think about organizing teams because some things that used to be expensive are not expensive. Some things are still just as challenging. So how do you see this current moment in terms of the way that we build software evolving?
- [37:31]
D
Right, Big question obviously, and I'll couch it with first saying that AI is only as good as its training data. And if you are trying to innovate and do something that no one's ever done before, you can't do that with just AI. So that's sort of maybe my self serving position. But that being said, there is a huge number of applications that I can see being useful. One thing that we found to be very interesting and reinforces our focus on high quality user stories is a feature we call Ask Capi. We have a capybara as our product mascot and you can engage with Capi on asking questions about the product that you built or the products that you've built. And you might initially think, well, why do I need AI to tell me about a product that I built? I built it so I know what it does. But of course that's not the way that software teams work. There's lots of roles that you know, maybe you are a product owner like me and you can't remember the details of a story that you wrote a year ago, or maybe you're a test engineer and you need to quickly find out whether a negative test result that you have is actually valid or not. Perhaps you're a support engineer and you need to know how the product works with regards to like customers expectations. Being able to quickly find user story references using technology like R G is extremely useful to get very fast answers. Like it's just beyond search. You know, search gets you so far and then you can start reading and digging and doing your archeology, but having that sometimes technical, sometimes old content be summarized for you in a concise fashion, just exceedingly useful. So that's an example of where I think AI really shines in this space in, in the product space. Lots of other examples. I won't go through our whole AI roadmap, but again, like what I started out with, you know, AI only being as good as its training data. You can really amplify the value of things like that if you have high quality user stories at the right level of granularity and so on. More broadly, one thing that I've found a little strange in the industry right now is the focus on agents and the anthropomorphization of your interaction with AI. So I do feel like in a Lot of products that I use that agents have been shoehorned into the product and the interactions feel very unnatural to me, actually. So just as an example, we're building a feature where you can have a suggested size for a user story. So based on other stories in your backlog that have been sized, here's three stories that we think are bigger, three stories that are smaller. So this one's probably this size. Interacting with an agent in natural language to do that feels actually more cumbersome than just press the button and give me the references. I've used this before. You don't need to be quite so friendly or cute or things like that. So now this is just my opinion. I think that we should just strive to have the best interactions for whatever the underlying technology is. We should just have the most natural and unencumbered interactions possible. So I do see that as the agentic trend seems to have gone quite a lot further than I expected.
- [41:01]
B
It's tough though, because we have arguably one of the coolest mascots in existence, the capybara. Who doesn't want to talk to a capybara?
- [41:12]
C
That's a good question. I suspect if you over index on agents, you might find out who doesn't want to. Right?
- [41:20]
B
Yeah, good call. Fair point.
- [41:21]
C
We're definitely in a hype cycle and everybody's trying to jump on the hype. What I'm curious though is like, so through your customer base you probably get a lot of window into what people are asking for or trying to do differently. And I'm kind of curious, are there things that feel qualitatively different about what people are looking to do in product development now? Or is this another example of, okay, here's the technology and we're jumping on the hype wave because I've heard opinions on both sides of that of like, this is changing everything or this is yet just another version of what we've seen. Every five years we have a new underlying technology.
- [41:58]
D
I think it's qualitatively different when it comes to prototyping software. It's. I won't name any particular product names, but you know, auto generating, let's say, mock ups graphics based on prompts, like verbal prompts, is. I mean, you can't really compare to what that would look like 5 years ago all the way through to like prototype software being generated in a similar fashion. I do think that that changes the game to some extent. I also, you know, understand, I mean directly from developers at Atono, some of the frustrations when it comes down to where the rubber hits the road. Auto generated code, you know, sometimes is more trouble than it's worth, like debugging something that that was. I mean, no developer likes any other developer's code, but they like AI generated code even less. So, yeah, I understand the skepticism too, but I think it is qualitatively different. But again, returning to my initial statement that if you're innovating and doing something that no one's ever done before, humans will always be involved. What do you think, Doug?
- [43:03]
B
It's definitely on the hype cycle scale. I mean, we just see organizations being pushed to, I don't know, AI something, go buy some AI. So, you know, I think that there's a lot of organizations just trying to figure out how to do it, how to get something in there, how to check a box. Ultimately, we're more concerned about user journeys. What is it that takes time out of my day, how do I get rid of some of that toil, how do I help streamline stuff? And there are different mechanisms for getting there. Do people really care what the algorithm is behind the scenes? You know, like some of these problems? If I'm trying to suggest risk rating to a bug, you know, how much of that is an AI problem or not? Could be, maybe it isn't. Ultimately, somebody needs a technology that suggests the risk rating. So don't worry about what's behind the scenes. I think that right now, because of where we are, you have to AI this, AI that, pull it all the way to the top. But I think in the fullness of time, we'll shortly see people being sick of the term AI this, AI that, and they just want those things done for them. You know, the feature will just be suggested risk ratings, not AI suggested risk ratings.
- [44:21]
C
Yeah, well, and I think to your point, right, like focusing on the user that hasn't gone away, there's no AI that's going to take the need to understand what does your user need and want and how can you incrementally deliver value towards that? We're getting close to the end of our time here. Before we wrap, are there any things we haven't talked about yet that you think would be important to leave our audience with?
- [44:45]
B
I don't know how much we covered feature engagement as an important, you know, cultural mechanism as well as metrics for decision making. But, you know, there's a pretty natural progression, in my opinion, from the feature flagging concepts about rolling something out and getting it out there and that having cultural ramifications as there is to, well, okay, now this thing's free. It's in the production world. Who's using it, how much is it getting used? And there certainly is the value related to the investments that you want to make and how much should you invest in something. But just as much in terms of empowering the product team to understand how that feature has gone out into the world and helped change the world. The teams don't usually get to see that stuff. You know, who has access to Pendo, who has access to Amplitude, who has access to all of those different tools? Maybe it's a pm, you know, maybe it's somebody on the customer support side. You know, it depends on why you're looking at those consumption type metrics. But bringing that all the way back to the entire team in the environment that they're used to working in is something that, you know, truly helps the teams feel like they're part of something bigger, as opposed to a bunch of mercenaries that chuck some code out the door and never see it again.
- [46:12]
C
That actually feels like a great coda.