Rob Monroe, Product Management Enablement Lead at Rise8, brings Steven Pereira and Paul Rayner back to the stage for a panel built to push past easy agreement. They compare value stream mapping, flow engineering, and event storming, and where each one earns its place. Paul describes going all in on AI-assisted development and why the bottleneck has moved to learning, both in understanding what to build and in validating what was built. Steven explains how AI makes high-cognitive-load work like planning, scoping, and challenging bias more accessible. Rob sets up a realistic scenario of competing blame across leadership, product, engineering, security, and acquisition, and the panelists share how they get started in a new organization. They close with one challenge each for Monday morning, including Paul's plea to draw a diagram instead of writing another 20-page document.

Rob Monroe:

It was the Cinderella story and how we worked through this in a workshop setting that has connected me more with my Disney Fanatic family. Unfortunately, every time we get into that type of conversation, they're immediately telling me, "No, no, stop. We don't need to hear any more of what you do or trying to explain this in this type of way." So yeah, thank you for that. Joining me back on stage is both of our guests, Paul Rayner, Steven Pereira. So please just have a round of applause for these two individuals. Guys, I just want to maybe start off. I know we only have 20 minutes. It's going to go really quick, but as first time attendees of Prodacity, what do you guys think so far?

Steven Pereira:

I'm a huge fan of outcomes. So this is just like hearing that repeated over and over again is wonderful. And hearing so many people talk about it in conversation to me makes all the difference because there's a lot of activity happening all the time, but getting results is really the thing that matters the most. So it's super refreshing to hear that and I'm enjoying it a lot.

Paul Rayner:

Love it. Yeah. I mean, you might have guessed from my talk, my background is not in GovTech, so I love being here because what everyone in this room does touches every single one of our lives in meaningful ways. And so I really enjoy being part of this crowd and seeing the interest and passion in mission and outcomes and wanting to meet real needs. So yeah, I've been enjoying. And I love brisket, so I'm sorry. I've gone for seconds every time.

Rob Monroe:

The food has been fantastic. Well, I'm really thrilled to have this opportunity to sit with both of you on this stage. Welcome to Prodacity. And I just want to say for this mapping the mission panel, we wanted to do something a little different. I think there's an easy tendency to want to agree to most of the conversation that's going on here. And let's face it, when we leave conferences, we leave with excitement, new knowledge, new skills, new relationships, and then we come back to work and the daily grind hits us. The friction points, the pushback, the folks that weren't in the room are starting to question whether or not these things should hold time and space. So I think to try to help get a jumpstart on building momentum, we have a unique opportunity, not just because of you experts on the stage, but I think we have this opportunity to have a real interesting dialogue to talk about key differences of opinions and nuances about these techniques, though both of them are very important at different elevations to our Mission O/S. So I kind of want to create some intentional conflict maybe, maybe force us to be a little bit uncomfortable with the conversation and take some strong opinions. So our goal is to tackle what I think was an underpinning question from today's keynotes. And that is how do we navigate ambiguous mission domains and complex systems in a way that drives decisive action? And I'll get more into why I think that's an interesting equilibrium for us to play with, but to maybe get us started, I'd love to hear your take on why your specific mapping frameworks deserve or are so vital to enabling government organizations right now, given what's going on in the world, given what's happening with AI, why should we take the pause to learn these techniques?

Steven Pereira:

I can start.

For me, I spend a lot more time talking about flow engineering than I do value stream mapping for those reasons. So the reason flow engineering exists as a distinct thing beyond value stream mapping is because I saw and I experienced a lot of struggle with this idea that you can just go in and start mapping. And I saw environments where we didn't know where to start, we didn't know who to invite in the room, we didn't know why we were mapping. People were brought in and they were unclear about what they were supposed to contribute. So the first piece of that puzzle, the outcome map, is really getting directly at the problem of why do anything? Why are we even pausing the work to think about the work or to reason about the work? And then the other end of the flow is the roadmap that really takes all those great ideas that surface and emerge and puts them into something that we can count on.

We can actually distribute and say, Phil owns this, Nancy owns this. They're going to show us progress in these ways and we know the time horizon when we can expect those outcomes. And I think that those are really critical pieces that any organization needs to kind of bookend any effort that they're undertaking, whether it's event storming, value stream mapping, wardly mapping, any kind of activity, even projects and efforts.

Paul Rayner:

Yeah. And I agree with what Steven is saying. And as I mentioned in my talk, I see event storming, it's another complimentary mapping visualization technique that starts from the perspective of the engineering team. Most development teams, engineering teams that I work with kind of lack some of the tools that would help them to engage the people that actually whose needs they're trying to meet. And so part of what I've been trying to do with this is to expose developers, engineers, QA, whoever it is that are involved with implementing the software, expose them to techniques that would actually be engaging and fun to do that sense making around what is the problem that we're trying to solve? How does it tie to the mission? Where's the value in this process? The vast majority of teams I work with, individuals could probably not articulate where in the business process that they're writing software for value is actually being generated for the end user and impact for their own organization.

They probably wouldn't be able to articulate that.

Rob Monroe:

There was this good session yesterday that talked about getting the right players on the field and getting everybody involved. And I think that's one of the fun aspects of these techniques is we get to bring people together and have deep conversations. It's not about the output of the map. I think there's a slippery slope here of taking these techniques back, codifying them as something that we do, and then everyone becoming obsessed with this idea that that's what it's about. We do this thing and now it's this new checkbox or it's this new theater element to planning. And I think we miss the real insights, which is the conversations that are going to be had both in that moment, in that session, as well as the things that are going to transpire afterwards and what we're going to learn and have to come back and rehash those conversations.

I found it was very interesting when working with some clients of ours earlier this year even, we're going to talk about a case study in the OOA, outcome oriented acquisition workshop about how quickly we changed mindsets and perspectives of how we needed to think differently for an upcoming opportunity. And a lot of the standard questions I get whenever we present this material is, gosh, it must have been really difficult to get all of those people in the room or really expensive. I don't think we could do that or pull that off. And the interesting thing that I always come back to is like, yeah, but so is 18 plus months of acquisition.

And then getting to the point of being able to finally pull a trigger on something and realizing that everything that we baked into this plan is actually not going to pan out the way we expected. And it doesn't have to take that much effort and/or fidelity, which we'll get into a little bit here in the discussion as well as with the workshops. Maybe to start to transition this into something a little bit more concrete, we have this velocity paradox in front of us. I'm going to kind of move the conversation more into continuous delivery and software delivery for a second. AI is empowering everyone to generate software at speeds that were unthinkable even a year ago. So my curiosity here is there's two, which is where do you believe AI provides the best leverage for mission mapping today and what boundaries do we still need to respect?

Paul Rayner:

The best leverage?

Rob Monroe:

Yeah.

Paul Rayner:

I went all in on augmented AI assisted development summer last year and to the point where my wife started saying, "Why were you up at 3:00 AM?" I was like, "I just had to get one more prompt in." I was building something.

Rob Monroe:

That dopamine is real.

Paul Rayner:

Dopamine is real.

Steven Pereira:

The next prompt's going to be the right one.

Paul Rayner:

Well, so one of the fascinating things for me is I've always considered myself more of a builder and a creator and have struggled with, like Kent yesterday talked about perfecting his craft and investing so much time in that. And I always felt like I would go into a team and I would be the slowest programmer on the team, the slowest developer on the team. And I was the bottleneck for that. And now with the tooling, these AI harnesses and that, that's now not a bug anymore. That's a feature for me. It's like I can come in and be as fast as anyone else. And what I've seen is that now that the actual generation of the code is the bit that is fast, like Kent mentioned working code as a side effect of a learning process. So I think the leverage is around how do we get better at the learning, right?

How do we get better at the learning process side of things, not only on the front end in terms of understanding what we're building, but also validating what we've built and then taking what we learn as we're going through that process and feeding that back into what we've already built to make it better. So that iterative kind of aspect of it.

Rob Monroe:

Yeah. It feels like we're talking about learning through validation of what really happens in production and we have this opportunity ahead of us to expedite that. But I think even in these mapping techniques and workshops that we can run, just getting to the answer of I don't know and being willing to say we don't know and we need to actually discover what has to fill that gap is critically important and it's very cheap to just have that conversation in a matter of 30 minutes to an hour. Steven, I'll punch it over to you and maybe take this in a slightly different way. If AI is going to help programs leadership achieve economies of scale, double 10X their delivery capacity throughput, I'm of the opinion that it was never about software development or delivery was ever the problem, but now for sure, where are the constraints?

Steven Pereira:

Well, now it's a problem because now we have way too much of it, right? We have way too much supply and not enough demand, or we have insufficient supply of what actually creates the best software. So the inputs, the initial planning and shaping and scoping and synthesizing the right information, challenging our biases, all those things are really big opportunities that can save you a lot of problems. We can all find 10,000 ways that don't work with AI, right? We can get to 10,000 really quick now, but we don't necessarily have to. We can get better at focusing our efforts on what we think is going to be the right approach, have AI kind of augment and support and inform that by synthesizing a lot of information, by giving us a better view of the bigger picture. And that includes everything from prioritization to scenario planning.

There's a lot of things that we don't do because they're difficult, because they're high cognitive load activities. And I think that AI makes those things more accessible and we should be doing way more of that in addition to the additional harnessing. I think the best continuous delivery environments are where I could try to break the system. I could try to build bad software and it will prevent that from happening. And I think a lot of systems are not at that level today, but that's where we have to get to if we want to make 10,000 attempts at the next flying machine.

Rob Monroe:

I would consider myself to be an extreme data metrics and scientific method nerd. And so when I think about this in terms of where do the constraints surface now, though I believe they've always been the case, is if we don't imagine what we're actually looking for in a change of behavior in prod, we've never actually known what the target was in the first place. We don't know what the destination is. And so I don't think it has ever gone away, but now it's going to be more important that we know this as we move at hyper speed. And then on the upstream side of this, I've been, I think, guilty of this in my own right of other workshops that I've held in the past for other organizations, which is I used to do this really annoying thing that we'd exclude the time and energy that it took to develop the backlog because we said there's too much nuance and too much variability of subjectively putting that together.

But I think we've been thinking about it the wrong way. I think we've been measuring the time and energy it takes a human to do this. Now we can maybe do that faster, of course, with AI. But then comes the conversation of like, well, what should the average story points be? And we start introducing these weird metrics that take us completely off course from what we really want, which was like, did we have the right bet and how do you know? And that's really what a product manager should be doing in the responsibility camp of understanding viability for what we want out of the mission, what we want in the hands of operators and war fighters. Let's take this even further. Let's make this more concrete. I think that this will resonate with some of the folks in our audience. So say that you're introduced to a program that takes roughly 18 months to get capability into the hands of operators.

Leadership thinks engineering needs to move faster, product says priorities move, are constantly changing engineering points to dependencies, security and acquisition are blamed for delays, critical domain knowledge is fragmented across fractal organizations and information systems. This sounds realistic, right? So Steven, if you only had one day with this organization, what would you want to make visible first and what are you trying to learn?

Steven Pereira:

So I have the luxury and the privilege of being able to walk into organizations and be the dumbest, most ignorant person there and just ask a bunch of. It's wonderful, isn't it? It's fantastic. So we get to go in and be like, "What is the most important thing to focus on? What is going on right now? Who is in charge of this thing and how do you know those things?" Which are really hard questions to ask when you've been there for 10 years. The chance to look dumb and not pay a price for it typically. So I think that's a huge opportunity and I take that very seriously, my ability to kind of ask dumb questions that maybe everybody knows the answer to and that's good signal or nobody really has the same answer for and that's also a good signal. So I want to know that, but really this outcome discovery, outcome mapping piece and trying to get to, is there a strategy here?

The first things I always want to know is the foundational things that are going to help me make all the following decisions, right? Everything that follows is downstream of, is this aligned to the strategy? What are we trying to get towards? Because I can spend so much time going down rabbit holes and dealing with it depends or all this variation in the environment, but what really matters most is what is the most important outcome? What is the direction that we're trying to head in so that we can all be helpful in this sense making exercise?

Rob Monroe:

I think this transition, whether it be output to outcomes or some other variation that follows a similar pattern is nothing new. I see teams that struggle with just being able to articulate what the constraint is even when it's staring at us in the face on a map and we try to overanalyze or become really creative with trying to explain it and it's simply just that. We need to move this thing from X to Y and what are all the actors involved? And so what do you think we need to do differently to really just finally change our brains and get us moving in the direction? How do you pull people through that to become more outcome oriented from a constraint and taking action with that?

Steven Pereira:

It's really difficult. I mean, it's why I need a target outcome. I need something that I can hold up and compare all the input to as a measuring stick and be able to ask the question and prompt the question, is this getting us closer to that? Is this relevant to the target outcome? Because I think we, in the weeds as individual contributors or part of a system, we become blind to what actually contributes to the outcome, right? There's fires burning everywhere. They all need some degree of attention, but there is one highest priority fire. There's something that's closest to something that's about to explode. There's something between us and the exit to the building. So trying to get to that is really where you need the outcome to actually force the conversation to focus and separate the signal from the noise.

Rob Monroe:

Yeah. Paul, you and I have had some healthy debate even at ShipSummit earlier this year around whether or not value stream mapping or maybe we could include flow engineering in the conversation here deserves time and space because we can do these really cool things with event storming, another technique that allows for some elasticity in the elevation. Maybe to push on Steven here a bit, what does Steven's approach help you see as a practitioner of event storming and what might still remain unseen?

Paul Rayner:

I think I share Steven's approach to coming in and asking a lot of questions. I have that ability as well. And being able to ask people to try to articulate the strategy, the vast majority of teams that I work with are not able to do that. And so I like to meet people where they're at and try to. I mentioned the hotspots is really map out all these, what are typically unknown unknowns and try to at least make them known unknowns that we can now address. So if a team maps out a process and they're like, "Well, one of the pink sticky says we don't know who our AO is," then it's like, "Well, that's something that if we could figure out all the rest of this, but if we can't actually get approval to deploy this, then we need to get on that."

Rob Monroe:

It doesn't matter.

Paul Rayner:

It doesn't matter, right? We need to have support at the leadership level. No amount of strategy or tactics is going to help us if we can't actually get through that gate. And so being able to identify those types of things. I've done other sessions where people are very concerned about certain pain points that are showing up, that once they map the process, they realize that those pain points they're experiencing in one part of the process are really just symptoms of something that is happening further upstream, completely disconnected from them and they're just feeling the pain of it. And some people have described that as somebody upstream is burning the toast and you've got a bunch of people downstream scraping the burn bits off the toast. And so there's that idea of baking quality into a process instead of inspecting for it afterwards. That's very hard to do if you don't have that overall visualization of how these things tie together, which a lot of teams lack because they're down in the weeds.

Rob Monroe:

Well, I think that that judgment and rationale that we can use to understand the story and make decisions is critically important. It's one of the reasons why I don't think we can just offload everything we do still yet to AI and our agents. For anyone that operates at different levels here, I keep using the term elevations and using these techniques together. It's because there's different people with different contexts within the organization. And one of the things that I think is really critical to get on board with here when we talk about outcomes is that we are making assumptions, we are needing to test those assumptions and they have these causal effects all the way from the highest point of mission impact and making strategy at that layer to how does this actually work? Why is this actually not going the way that we want it to be? It's just cause and effect chains and it can get really complex, but it's really fun in my opinion to be experimental and to try to move the needle and try to move the constraint elsewhere based upon those assumptions. I know we're coming up on time here, so I'm going to push us along and I think something that would be I think appropriate to maybe be thinking ahead of time going back to work after Prodacity here would be, do you think that after all the reps that you've had and engagements with different organizations, do you find it's harder to get started or do you find it's harder to follow through? I'm going to challenge you both to take opposite stances.

Steven Pereira:

Do you mean as a consultant? I do think that, well, getting started means going through procurement, which is the hardest thing in the world. But I think that as a consultant, there's a lot of organizations that are looking for the map. They want the artifact, they want the picture, they see a lot of value in that. They don't necessarily see so much value in the mapping, which is what we all think is critically important, but much less - on the artifacts. Yeah, much less tangible. But ultimately the thing that I think is really hard is operationalizing the capability. I try to leave organizations with like, this is a thing that you can do and you should be doing. After I leave, someone should be doing this every six months and do it all over the place. So I think that's the hardest part is operationalizing it, making it a part of the culture, the behaviors, the operating model.

Paul Rayner:

Yeah. I mean, with something like event storming, there are maybe teams that would not be a useful practice for them, but teams that are able to operationalize that, to use some kind of technique for visualizing and doing sense making, especially when they're in a complex environment where maybe they need to try something, experiment, see the results and then incorporate that into the next iteration. I think operationalizing that can be really tricky if you don't have the support, if you don't have the ability to feel like you can run a small experiment and learn from it, especially if you have pressure just to churn out features, right?

Rob Monroe:

Yeah. So maybe what we're saying here is if the mental model is just trying to reinforce certainty and total clarity above all else, we're probably not helping ourselves move in a more outcome oriented direction. We're likely going to do things like contractor shall deliver value stream map in this format. We might do these things that make it about the output yet again, instead of really getting after what was it that we were trying to discover. And so I would really implore everyone to really take off the mindset hat of I need to be right. I'm doing this because I'm trying to prove I'm right versus we're trying to find a way to make it safer to learn and learn very quickly and get everyone on board with what the conclusions and what the outcomes are of those discoveries really surface. Any closing final thoughts of things that people should take home with them?

First thing you would challenge them or to go do on a Monday morning?

Steven Pereira:

One of the things, I think that really the equation here is yes and we do need mapping at every level and we do have to connect the dots. It doesn't have to be extremely difficult to do that, but I love the combination of value stream mapping at a high level and then where I find a hotspot to do a very detailed event storming. I find that that combination is super, super valuable. So I encourage people to think about how you can use these tools together in different contexts and get the best of every technique. That can be very difficult of course, but I think with our AI assistance helping us disentangle these complicated things, it's more accessible than ever. And we may be early days in being able to deploy these things, but that's where I see a ton of value.

Paul Rayner:

I'm just going to talk about a pet peeve. So what I'm seeing in organizations now is with the advent of large language models is suddenly everything becomes like a 20 page Word document or markdown file and it's just a sea of text and for goodness sake, draw a diagram, sketch something, visualize something because we're wired for visuals and don't give me a 20 page PRD and expect me to. All I'm going to do is just throw it back into the LLM and ask it to summarize it, right? So stop doing that if you're doing that. Stop that and start visualizing, start collaborating and that's my pet peeve. I'll stop talking.

Rob Monroe:

I feel so seen right now. Steven, Paul, thank you guys so much for this opportunity. I always learn something new from you guys every time we have an opportunity to speak and yeah, thanks for being at Prodacity and thank you all for being here as well. Thank

Steven Pereira:

You so much everyone. Yeah.

‍