Episode 07

Bryon Kroger (00:05):

We've spent the last two episodes architecting for continuous delivery. We've established the path to production powered by a cloud native platform built for speed and security. We can now ship software safely, quickly, and sustainably. The question we need to answer next is the most important. What should we be shipping? Having a world-class continuous delivery pipeline is completely [00:00:30] useless if the application's running on it don't solve real problems for real users. And this is where delivery meets impact. Today, we're talking about how to build winning applications that users actually love to use. And the journey starts by rejecting the traditional siloed architecture of the enterprise. The old way is a game of telephone, right? A business analyst writes a 500 page requirements document, [00:01:00] throws that over the wall to a designer. The designer creates a sets of designs and mock-ups, throws those over the wall to a team of engineers, and the engineers build what they think meets the request.

(01:12):

And a year later, maybe two or three or five, everyone is shocked when the final product doesn't work and nobody wants to use it. That model is fundamentally broken. The Mission OS approach starts with a different framework. The core unit of value creation is a balanced [00:01:30] team practicing dual track development, shipping weekly iterations to production. A balanced team, as we define it, is a small, fully dedicated group of people from three essential disciplines. First, you have product management. They're the voice of the mission. Their job is to constantly ask, "Are we solving a valuable problem for the mission? Will this create a meaningful impact?" They own the why. Now, in a traditional product organization, [00:02:00] the product manager is actually going to be responsible for the business. Is this a viable business? But when you're in B2B or in this case, B2G, and functioning in a way that more closely resembles internal product development or internal IT, the product manager takes on this different role.

(02:23):

They're not concerned...for instance, a Rise8 product manager is not concerned about what's good for the Rise8 business. [00:02:30] They have to make the customer's mission their mission. They have to be thinking, "Are we solving a valuable problem for the Air Force, for the Army, the Navy, Veterans Affairs? And will this create a meaningful mission impact on their mission?" That has to be their why. And this is very different than a traditional product manager at a product organization. And so it's important to distinguish between those two and make sure that whether you're hiring a contractor [00:03:00] or you're a contractor trying to hire product managers, that you're thinking in this way, that that is your why, that the customer's mission is your mission. Second, you have product design. They are the voice of the user. Their job is to understand the user's context, their pain points, and their workflow.

(03:20):

And then they ask, "Are we solving the problem in a way that is usable, intuitive, maybe even joyful?" Funny thing to say in the military. [00:03:30] They own the who and the what. And it's really important that your product managers don't get conflated with your designers. It's very easy for product managers who don't understand mission context to fall into the trap of being a second voice of the user. These two disciplines often have healthy tension between them. What's good for the mission and what's good for the user? You have to find the intersection of those two things and they don't always overlap. Third, finally, [00:04:00] you have product engineering. They are the voice of technology. Their job is to take the what and figure out the how. They ask, "Can we build this in a way that is feasible, secure, scalable, and maintainable?" And when you put these three together, magic happens.

(04:18):

It's at the intersection of these three perspectives. When these three disciplines are in constant collaborative conversation, you get products that are valuable for the mission, delightful for the user, and feasible to build and operate [00:04:30] for the enterprise. This isn't a handoff, it's a partnership. I also want to highlight that this is just the core team. From here, we can add other disciplines as necessary depending on the context of the project. But let's break down each of these core disciplines. For product management, the guiding philosophy should be lean enterprise. Many of you have probably heard of the famous lean startup by Eric Ries who popularized the idea of building a thin vertical slice. Instead of trying to build [00:05:00] a whole car at once, you build the skateboard, the scooter, the bicycle, the motorcycle, you've probably seen this famous graphic, and it's a powerful concept. But in a large enterprise, it has a dark side.

(05:11):

I call it the lean trap. A team builds their skateboard, right? They get their first app and they get really attached to it. They fall in love with their little slice of the world, and they spend all their time and energy making it more and more joyful. Of course, they think they're building a car, but in the context of an enterprise, it's still a skateboard. [00:05:30] Now it's got racing stripes and better wheels, but they completely ignore the massive opportunities around them to the left and to the right. They get stuck in local optimization. But when you're zoomed in on your product, you can't see that. It still looks like yet another valuable thing and your users are telling you, at least the ones you're working with, that it's a very valuable thing. A lean enterprise product manager has a wider aperture. They use tools like value stream mapping [00:06:00] to understand the entire mission context, what exists to the left of me, to the right of me, upstream and downstream.

(06:07):

They know when adding racing stripes is the right call, but they also know when the next most valuable thing they could do is build a bridge to the team next door. And so they balance the needs of their product with the needs of the enterprise. Next, let's go deeper on product design. The foundation here is and always will be user center design. You have to start with the user. You have to have [00:06:30] empathy for their reality, their struggles. You have to get out of the building and watch them do their job. This is a non-negotiable. But in our world, the user's not an island. They're a member of a larger organization serving a greater mission. And I really want to emphasize something here. There's a difference between user-centered design and user-driven design. Some people don't like this nuance when I bring it up, but we don't want the users to drive the design.

(06:57):

Users should [00:07:00] drive the pains that we're focusing on. They know their pains better than anybody, but they're not professional designers. There's a famous quote that's often attributed to Henry Ford. He never actually said it, but it's, "If I asked people what they wanted, they would have said faster horses. We never would have gotten cars by asking people what we should build." But we focus on a pain and then designers and really creative people come up with solutions to those problems that users could have never even imagined or might not have ever [00:07:30] even seen. And so this is where we introduce the practice of service design. Service design zooms out and maps the entire service blueprint. All of the people, the processes and the tools involved in delivering a capability and delivering on a mission thread. It helps us find that critical intersection between improving the life of an individual user and making the overall mission more effective.

(07:55):

And sometimes the most valuable thing that you can do for a user is something they would [00:08:00] never think to ask for because it solves a problem three steps upstream they've never even seen and that they've been the victim of on the receiving end. Finally, our third discipline, product engineering. With a solid platform and path to production, our application engineers are free to focus on writing clean, high quality application code. And the methodology we use at Rise8 is Extreme Programming or XP. Now you don't have to use XP, but what I [00:08:30] will say about the various agile methodologies is that most of them are focused on management and not the actual engineering work. So whatever methodology you use, make sure that you emphasize discipline engineering practices. XP, for instance, what we use is a set of practices designed for one purpose to allow a team to go fast, safely, forever.

(08:55):

Now highlight just a few core ideas. First is test-driven development. You write [00:09:00] automated tests before you write any line of code. The test fails and then you write just enough code to make it pass. This creates a safety net and it gives your engineers the confidence to constantly refactor and improve the code base without the fear of breaking something. And so this practice of test driven development is all in service of going fast forever. As is this next practice, which is pair programming. Two engineers, two keyboards, two mice, [00:09:30] one PC, or Mac. One member of the pair is driving, writing the code while the other is navigating, thinking about the bigger picture, catching mistakes, considering alternatives. And this is a very conversational process. This isn't two people doing one person's job. It's a continuous real time code review, and it drastically increases quality, eliminates knowledge silos, and it's one of the best ways to also mentor and grow your [00:10:00] talent.

(10:01):

A third practice is continuous delivery built on continuous integration. So every time a developer makes a small change, it's automatically integrated back into the main code base and tested. And so this prevents the nightmare scenario of a "merge hell" where teams work in separate branches for weeks, months, or I've even seen years, and then spend days, months, or years trying to smash all their code together. True continuous integration keeps the code base in a constant state of readiness, [00:10:30] which unlocks continuous delivery. Which in the book Continuous Delivery ,by Jesz Humble and Dave Farley, they define as the ability to ship changes of any kind into production quickly, safely, and sustainably. Now, a balanced team practicing lean enterprise, service design, and in our case, extreme programming sitting on top of a solid platform, is the formula. This is how you move beyond just shipping code to start continuously delivering applications [00:11:00] that users actually love and that create undeniable mission impact.

(11:05):

We can add other disciplines to the balanced team as needed, but these three are core. But building great software isn't enough if the culture around it is broken. In our next discussion, I'll show how attitudes and beliefs shift when teams and stakeholders experience what's possible with new ways of working. Real results delivered rapidly and reliably change [00:11:30] minds and changed minds are what change culture.

(11:44):

So I often find myself having to coach product managers out of the lean trap. There's a very recent one inside of Rise8, internal R&D product, and I think there's a tendency...in fact, the entire Silicon Valley narrative has been to build [00:12:00] these thin vertical slices, but there are some newer founders like Parker Conrad at Rippling that are advocating for something entirely different, which would be the compound startup. So instead of the lean startup, the compound startup. And the idea here is that especially inside of large enterprises, these point solutions actually become ROI negative and instead, it's better to build horizontally and cover a big end-to-end swath of the value stream, [00:12:30] even if it means having less depth on each one. And so this is something I see time and time again, but this particular product is meant to solve a very large enterprise problem when we talk about the long-term vision for it.

(12:46):

But I kept finding that the team was going deep and narrow, and if we took that approach, it would take years to build out a product that covers this entire value stream, but that's where the value is, that's where adoption can happen. And so [00:13:00] the product manager's not wrong when they see that there's still massive value in this vertical slice. The question's one of strategy, and you have to really understand when you move left and right in a value stream, the first thing you do is incredibly valuable, and the second and third and fourth follows a power law curve.

‍