Empowering Cross-Functional Product Teams with Tobias Dunn-Krahn and Doug Peete

0:00Modern 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 Donkron is the CTO, and Doug Peet is the Chief Product Officer of Atono, which is a software development lifecycle platform focused on cross-functional teams.

0:45They 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 in product tooling, and how to unify product, design, engineering, and operations in a single workflow. Kevin Ball, or KBall, 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 KBall on Twitter or LinkedIn, or visit his website, kball.llc.

1:37Hey guys, welcome to the show. Hello. Hi there. 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. Okay. Hi everyone. My name is 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.

2:22So 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've built Atono. But before we get too detailed on that, I'll pass it over to Doug. Hi, my name is Doug, and I'm Chief Product Officer at Atono. Like Tobias, I come from the 1900s, I've been building and designing software for a long time. I'm a geek at heart. I 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.

3:12So typically forming with Tobias, a dynamic duo, building out strategy, building out road maps, building out products, getting all the way down to the feature levels that we built together. Well, 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 longstanding 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.

3:48Sounds good. So Atono does do a lot of things that you might be familiar with from those longstanding tools and some of the up and coming tools for managing the software development lifecycle. 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. So we acknowledge that when a story is complete, deployed, shipped to production, that's not the end of the lifecycle.

4:33So Atono 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.

5:14We 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. 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.

5:47So 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. I didn't know we were allowed to say that on this podcast. 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? Sure, yeah. And without going too far back in history, I do see this as a fairly straightforward evolution.

6:23If 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.

7:03It allows for even larger companies that have scaled up to still act like a bunch of little startups and 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.

7:47And 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. 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.

8:29I 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 the consistency of most product teams, you have PM, a product owner, designer, but a bunch of engineers.

9:10Like 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. 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. Let's dive into that concept because I think that's something that I've seen it showed 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.

9:52And 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? 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.

10:34So 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 opinionated 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.

11:25So 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. 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.

12:06So 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.

12:47It also unlocks some of the behaviors that Tobias has 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. 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 like 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?

13:53Like, what does that all look like? So for just like a very practical application of that, I don't want to go by without mentioning this because it's sort of like something that's irritated for years, which is when you reference an acceptance criterion in, say, chat, Slack, or whatever, you're usually doing it by numbers. So like AC1BI, 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.

14:32And 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.

15:14So it allows you to do some 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:52Yeah, 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 in your product user analytics. Very interesting. Are they still like distinct to a story? Can you share across stories or like there any other sort of interesting dynamics that come by making this a standalone entity? 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 up-level objects.

16:31And 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 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.

17:11But in any case, that type of automation is facilitated by having acceptance criteria be first-class objects. I would also pile on that in terms of being able 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. 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, ah, 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.

18:02So it unlocks a lot of things so far, and we're finding many more behaviors as we go that it helps unlock. Totally. Well, 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 can 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? 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.

18:42Like 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 ag and manipulate and so on. So we definitely didn't want to compromise on a lot of structure at the expense of a user experience. 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.

19:25Are you familiar with the invest mnemonic? It's probably worth going through it quickly for anybody listening. So invest is a mnemonic and it speaks to the attributes of well-written stories. I don't know if going through every one of the bullets is 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.

20:04The N in invest 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. 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? That's what 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 you keep things small.

20:48When 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 the features in our own product is supported? It ends up being kind of meta because we're building products to build products.

21:29But yes, when we think about how we build the tono, it often comes back to invest the decisions that we make. 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 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 a bad idea in general. It just can be a lot of paperwork. So anything we can do to reduce that friction, we will do.

22:09I do think it's interesting on the design side. I think that developer tooling in terms of like continuous deployment and just general CICD pipelines have been improved over the years so that there's less resistance for engineers to ship small increments as 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 come up with individual designs for each of the decomposed stories.

22:53I 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. We'd like to party with you. Reach out to us. 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? 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.

23:29I find it's pretty common for PMs to not shoot for the M in MVP, minimum viable products. 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 you deliver valuable increments and what is value and really pushing each other to make sure that you get there. And the engineering teams doing that as well. And then providing the tools to make it so that it's just second nature.

24:14It'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. 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 host shipping, recombining stories that were split up for the purposes of independent shipping. So just as a slightly more concrete example, you would have an epic that was decomposed into 10 stories.

24:57Perhaps 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 archaeology, 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.

25:29So same thing for collecting usage data. Perhaps if you're looking at usage data across seven different related stories is maybe not as convenient as a combined story. 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. 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.

26:03So 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 and its connection to stories? Yeah. So I'll just take you through a typical workflow. So 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 release it across my stages 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.

26:44And our flagging system is based on OpenFeature, which is an open source flagging framework, which is a couple of advantages. First, for customers, it makes it easy to swap in and out flag providers. So if you decide, like Katona Flags, you want to use some competitor or 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 Open Feature 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.

27:33So 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 to have reference for exactly what functionality you're turning on and off from the place you're doing it.