Scaling Success: How Cornerstone Elevates Product Portfolio Management with Dragonboat

Join us for a fireside chat with Greg Shintani, Senior Principal Program Manager, Product Strategy & Operations at Cornerstone, as he shares how they’re using Dragonboat to drive alignment, speed, and clear impact across a complex product portfolio.

In this session, Greg walks through Cornerstone’s approach to:

• Capacity & Resource Planning: how they align resources and priorities during PI planning and major release cycles.
• PDLC Innovation: how their use of the Product Development Lifecycle app leads to faster and more effective reporting and team collaboration.
• Tool Integrations: how they connect Jira and UserVoice to Dragonboat to streamline feedback, strategic planning, and execution in one clear source of truth.
• M&A Portfolio Management: key strategies for bringing teams and workflows together after acquisitions.

This isn’t a polished case study. It’s an honest look at what worked, what didn’t, and how they turned scattered planning into connected execution. If you’ve ever tried to align strategy, delivery, and outcomes across teams, this conversation will hit close to home. Watch now to hear first-hand from one of Dragonboat’s strong power users.

Key Takeaways

• Streamlined Quarterly PI Planning for Efficiency and Alignment: Cornerstone leverages Dragonboat during PI planning to align resources, scope, and capacity across development pods, ensuring transparency and execution consistency even in complex release cycles.
• Enhanced PDLC Tracking for Faster Delivery: Using Dragonboat’s Product Development Lifecycle (PDLC) app, Cornerstone improved collaboration and clarity by simplifying milestone tracking and offering a single source of truth for deliverables at scale.
• Visibility Across Complex Workflows: By integrating multiple Jira instances and UserVoice into Dragonboat, Cornerstone consolidated disparate data into a cohesive portfolio view, enabling faster decision-making and alignment.
• Adaptable M&A Portfolio Integration: Dragonboat supported Cornerstone’s acquisition strategy, offering scalable workflows and phased onboarding processes to unify teams and portfolios while respecting unique or legacy systems.
• Data-Driven Decision-Making Through AI: With AI capabilities in Dragonboat, Cornerstone identified patterns over multiple release cycles, optimized resource allocation, and uncovered opportunities to improve delivery efficiency across their portfolio.

Transcript

The following transcript has been altered for readability.

Welcome and Session Overview

Camila Souza: Hi, everyone, and welcome. Thanks for joining us for another session in the Product Operating Excellence mini-series hosted by Dragonboat and Product Ops HQ. I am Camila Souza, Head of Customer Success at Dragonboat, and I will be your host today. 

In today’s session, we’ll be covering how Cornerstone elevates Product Portfolio Management with Dragonboat, featured by Greg Shintani, Senior Principal Program Manager for Product Strategy and Operations at Cornerstone. Greg will share how his team leverages Dragonboat to drive alignment, efficiency, and measurable impact across a complex product portfolio.

Before we dive in, just a quick note on how today’s sessions will run. I’ll be leading the conversation with Greg for the first part, followed by a live Q&A towards the end. Please drop your questions into the Q&A box right below, and we’ll keep an eye on them and get to as many as possible. And yes, don’t worry, the session will be recorded, and you’ll receive the play link afterwards to revisit or share with your teammates.

Today’s session is brought to you by Dragonboat, a platform that helps product leaders and teams make faster, smarter decisions, so they can strategize and deliver at AI speed and scale, powered by Portfolio Intelligence. Dragonboat is trusted by thousands of teams and leading enterprises, including Cornerstone. You can learn more by going to our website at dragonboat.io, and Ana will share the link right on the chat.

Introducing Greg Shintani, Sr. Principal Program Manager for Product Strategy and Operations at Cornerstone

Camila Souza: With that, I am excited to welcome Greg. Greg plays a pivotal role in Cornerstone’s product and strategy operations division, helping translate strategic goals into scalable, repeatable ways of working. Drawing on deep experience across product management and operations, he’s redefined how Cornerstone plans and delivers its product portfolio, building frameworks and driving adoption of tools like Dragonboat to improve visibility, alignment, and execution. Greg, thanks for joining us today.

Greg Shintani: Thanks so much, Camilla. Thanks for having me. Really excited to share my experiences with everyone. A little bit more background, too. I’ve been in product management and strategy and operations roles for the better part of the last 10 years. I’ve held positions ranging from the VP of product at a small startup, all the way to my current role in the product strategy and operations team at Cornerstone. So, I’m hoping my experiences today can be of value to you all and, excited to get into it.

Camila Souza: Awesome. Well, we are excited to hear all, that you have to share with us, Greg. So, if you don’t mind, let’s just jump in.

Greg Shintani: Let’s go!

How Dragonboat Supports Cornerstone’s Quarterly Planning and Resource Allocation

Camila Souza: All right, so, Greg, I know Cornerstone has already wrapped up their quarterly planning, but a lot of us are in the midst of it, and some of us are a little behind. So, the big question in the room today is, can you talk a little bit, how Dragonboat supports Cornerstone’s quarterly planning and resource allocation for major releases?

Greg Shintani: Certainly. So, background context for just setting the stage. At Cornerstone, we follow a scaled agile framework approach. For those that are unfamiliar with that specific methodology, it is somewhere in between true Agile and Waterfall. As a large enterprise company, we have to meet a lot of compliance and regulatory guidelines. In order to make sure that our customers understand what we are delivering, we do need to make sure that we’re communicating what’s going into each release, and be pretty strict about making sure that we are delivering what we say we’re going to do.

So how do we do that? So, Dragonboat is our product portfolio and roadmap planning tool. We have set up processes so that way, every single time we’re about to start a release cycle, we have a very rigorous planning exercise called PI planning, or program increment planning, that we conduct as an organization.

To just outline the process, all of the development pods that we have will get together and identify all the candidates that they’re putting forward for the release, they will align on the scope and the requirements, and they’ll do rough estimations at the EPIC level, to understand what essential or what effort it will take to complete all of those items.

Simultaneously, they will identify the total capacity for their pods, for that specific release, and then, through the PI planning exercise in Dragonboat, they will commit capacity against each of their epics, toward their total capacity. At the end of your PI planning exercise, you will then walk away with a specific set of epics and capacities that you are essentially committing against your total capacity for each pod.

Along the way, we do collect a lot of other information, like what capacity allocation each epic is assigned to, what initiative or strategic bets are associated with each, so that way we can also report off of those for leadership or for other cross-functional stakeholders.

How Cornerstone Handles Mid-Quarter Changes When Capacity Is Already Set

Camila Souza: Awesome, this sounds quite of a thought-through process. I have a couple of follow-up questions to that. We all like to plan, but we also know that over time, as the quarter develops, there are always changes. So, what is your take on how do you account for those changes in the next quarterly planning when capacity is already set and resources are already assigned, how do you manage those changes? How do you slide them in or take them off? And how is that decision process made?

Greg Shintani: It’s a great question. I think every organization will obviously encounter disruption, right? You’ll encounter ad hoc requests coming from certain customers. You’ll have escalations that come from a bug that you didn’t catch until the middle of the release. And so how do you account for that? We will essentially come up with these capacity plans, or during PI planning. But with the recognition that not everything always goes to plan. 

In JIRA, when something does come up, we have escalation processes and flows where we’ll loop in the right stakeholders to help out with prioritization decisions. Like, do we disrupt what we have planned, or do we stay the course and just punt what has recently come up in the middle of the release to the next release. Those conversations just naturally happen, and once those decisions are made, you will end up with all the stakeholders in JIRA naturally just moving those tickets, either to the backlog or pulling things in, moving things out, right? Things change.

So, for us to make sure that we can at least reference what we originally planned, to make sure that we’re tracking these changes over time, after we do PI planning in Dragonboat, after all of the capacities have been committed, and each pod has their game plan for the release, we take a snapshot. Dragonboat has native functionality to capture this data with snapshot functionality. You could also just export it. We generally just export it into a spreadsheet, so that way we can also pump it into some of our BI tools, like Tableau, for some downstream reporting that we also set up in our own custom dashboards.

But when you have that snapshot, then the following release, you can always reference back to it and say, what did we originally plan, and what did we actually end up doing? And so you can actually rely on the data as it is in Dragonboat or Jira after the release to see what you actually completed, and then reference back, well, how much did it actually change from what we originally set out to do.

And then when you go into your next planning, you can then say and make more informed decisions based on what happened, right? Do we need to account or add more buffer room for those ad hoc things that come out in the middle of the release, or maybe we’re realizing we significantly underestimate the actual effort it takes to do some of these things that we’re committing to, and so we can make more informed decisions of being more accurate with our estimations in the following releases later on.

How Cornerstone Maintains Visibility During Mid-Quarter Shifts and Communicates Trade-Offs to Cross-Functional Stakeholders

Camila Souza: That’s awesome. That’s definitely a good insight on how you maintain the visibility when the priorities shift. That’s great. And then, the other piece of it, as things change and you’re looking back on what you planned, and then looking at what you’re being able to deliver, there’s a communication factor there, right? On your role today, how do you communicate the capacity constraints or trade-offs to non-technical people that will have to make on the upcoming quarter, due to shifts to the previous quarter?

Greg Shintani: Yeah, that’s a great question. So, again, with Dragonboat, the primary end users in our organization are obviously the product managers but we are still able to provision view-only access to stakeholders across the organization, so that way we can be very transparent what is and is not going to be included in the scope of the release.

While Jira can be used for that too, at least in our organization, the access is restricted to JIRA to prevent additional noise or people accidentally changing data that they shouldn’t be. And so, in order to prevent that, we’re able to create views, share those views out to the necessary stakeholders so they can keep an eye on things. If they have a question, they can reach out to the right PM based off of the PM that’s assigned to whatever roadmap item they’re curious about. And then, if they really need to, they can then escalate it up the chain to kind of figure out, “hey, I actually need item A addressed in this release, can we squeeze it in at all?” 

Advice for Companies Struggling With Resource Planning at Scale — How to Set Up Dragonboat

Camila Souza: That’s awesome. Okay, so you have walked us through how Cornerstone does quarterly planning, the framework and the process, and then how do you actually manage the changes, and plan for the upcoming quarter, how do you keep track and communicate those shifts and priorities, and trade-offs. The last thing that I want to ask related to the planning topic is, for companies struggling with resource planning at scale, what advice would you give them when setting up the Dragonboat instance, or tackling this process?

Greg Shintani: My advice is twofold. The first is…don’t design your process in a vacuum. When we first rolled out Dragonboat and our processes that we tied to Dragonboat, we started at the top of our organization. We had this need to standardize things, to streamline things. There was a lot of work that was being done in hundreds of spreadsheets that were just all over the organization, and different folders, and SharePoint, and etc. And that was causing issues, not just with product organization but with the wider organization. So, what we did was, we went out to the leaders of these different organizations and said, hey, this is what we’re going to be doing, this is the tool we’re going to be using, this is our game plan. And then we got their buy-in first, understanding just the problem and recognizing the value of what this initiative was set out to do. And then we asked them to identify and put forward a couple of stakeholders from their team, so that way we could then work with those specific stakeholders, putting together somewhat of a working group to really make sure that we were listening to, and getting inputs from all the right points of contact at the organization. So that way, when we actually rolled out a process, we had buy-in from these key stakeholders across all of these different divisions, so that way they didn’t feel like we were just forcing something on top of them, just another bureaucratic process.

The other piece of advice I would share is to start small and just keep it simple. One of the things that I think we sometimes get caught up in is, let’s make sure that this can solve all of the problems, all at the same time. Shotgun approach. When you do it that way, then it becomes really challenging to manage all of these different requirements. It’s also harder to explain the value of, say you adding 50 fields up front and say, you need to fill out all 50 of these fields for every single epic, you’re gonna have a mutiny, right? All the PMs are gonna, like, say, there’s no way on Earth I’m ever going to fill out all this information for every single thing. So, start small, start with just the bare minimum, run through it with your stakeholders, for a single release, learn from it, then follow up with feedback, and then iterate just like any product development cycle.

Camila Souza: That’s great advice, you’re absolutely right. Most of the time, when we see folks rolling out Dragonboat, they are excited. So there is this big push in setting things up, and then trying to push down to everybody without cross-collaboration, revisit everybody’s needs, and adjusting to that. So the simplicity goes right out the window when it comes to that, right? So, I love the advice that you gave: keep it simple, identify your leaders or your key folks from each of the teams, and then collaborate so you don’t design your framework and your process into a silo, which eventually will do you a disservice because you won’t be successful. So, thank you for that very insightful lookback on how Cornerstone does, and then the advice to the folks that are going through it right now, and trying to figure out the best way of implementing Dragonboat. I appreciate that.

What Is Cornerstone’s Definition of PDLC, and How Does Dragonboat Support It?

Camila Souza: Alright, so I want to shift gears here a little bit and talk about PDLC. Before I jump into questions, if you can help set the context for our audience on what Cornerstone’s concept of PDLC is as a whole, and then maybe you can dive into how Dragonboat supports Cornerstone on that.

Greg Shintani: Definitely. PDLC, to create an acronym for Free Safe Zone, PDLC stands for Product Development Lifecycle. Essentially, from the initial ideation of you, as a PM, coming up with what you want to target for your next release, to then executing that and releasing it. There are all these milestones and deliverables that are asked of you as a PM to make sure that you get everything ready to go. As a PM, you’re asked to make sure that your requirements are there, and put together your user stories. In larger organizations with QA, you’ll also need to have test cases prepared. And then you’ll also need to prepare documentation and communications for the go-to-market team, so that way they know what to share with your end users at the end, once it’s all fully released.

So, every step of the way, there is something that you need to be working on to make sure that what you are trying to deliver is fully understood by all these relevant stakeholders, and cross-functional stakeholders at that. 

Especially in larger organizations like Cornerstone, where I am today, every single milestone or deliverable tends to be owned by a different stakeholder or a different organization. Marketing might be reaching out about communications you might have, solutions consultants reaching out about, like, hey, I need to know the full list of all the things that you’re going to be targeting, right? And so, how do you set a process and essentially manage your PDLC so that it is streamlined enough that PMs can follow it without being too bogged down with all of these processes, and making sure that you can get all this information to your relevant stakeholders?

Generally, what tends to happen is that any new requirement that comes up, we need a way to track this. That generally, with JIRA, is solved by, let’s add a custom label, let’s add a new field, let’s add something that we can just filter for this on, or tag this to. Then you end up with a graveyard of fields that don’t mean anything to anyone, maybe, like, a year from now.

That’s a huge, huge issue, especially just from a system admin perspective. You have new folks coming into the organization all the time, they’re seeing 50 fields, and I have no idea what this one is for. Even though you have documentation up the yin-yang, you still can’t get people to understand what each one is for.

So, what is great about Dragonboat is that there is a PDLC functionality in Dragonboat where you can essentially create a very specific set of custom fields, essentially, or columns in the spreadsheet, if you will, that can be used and tailored to a very specific use case. And so for our PDLC, we can set up a column for each milestone, and those columns can then be used to track each epic, which are essentially your rows in a spreadsheet, and track each deliverable that needs to be completed for it, so that way you have a single source of truth of all the things that you need to deliver for a specific epic. And then you’re not bogging down all of the, you know, when you create a new epic up front, you’re not seeing all these fields all at once in your face. It’s only for that very one explicit use case of monitoring your roadmap items throughout the release, to make sure that you’re delivering these things to all these relevant stakeholders.

Again, the great thing about Dragonboat is you can share that view with all of those cross-functional stakeholders, so then they’re not going and knocking on PM’s doors every other day for updates saying, hey, why did you not get me this yet? They can just see directly in this view, and if it’s not updated, then they can follow up. As an ‘as-needed’ basis, rather than a `I just need to ping every day’, because that’s the way it works.

Why the Choice of PDLC Fields Matters, and How Cornerstone Decided What to Include When Setting Up the PDLC Module

Camila Souza: Absolutely. I think that’s a very valid point. I want to double-click on something that you said regarding to how folks think about PDLC and the amount of information they think is necessary, but going back to the point you made, the custom fields and the amount of custom fields that you do tend to add to your standard PDLC sometimes can backfire. Can you tell me a little bit more about why the fields you choose are so critical? And for Cornerstone specifically, when you were setting up the PDLC module, what considerations did you take in mind besides the number of fields. And then, how did you come up or decided that the number of fields that you have will be sufficient, in order to scale, and get folks to really come in and populate the information so you can get he efficiency that you need?

Greg Shintani: I think the great thing about the PDLC module specifically is that you can create multiple subsets of these groupings of fields, right? And then when you set up a view, you don’t have to show every single field all at once. And when you create an epic, you’re not, again, blasted with, like, hey, you need to fill out all these 30 different fields. It is literally just a very specific use case that you’re setting up. And so then you can cater the field that you need just for that one specific use case, and set that up for cross-functional tracking. 

We at Cornerstone actually don’t just use the PDLC module just specifically for PDLC. We also use it for, especially this year, a lot of initiatives have come up that require very specific interlocking between different stakeholders that aren’t just explicit to product. And in order to make sure that we’re being able to, as program managers, my team, we have set up specific PDLC subsets of fields, so we can just have PMs that are associated with this one specific use case, or this one specific initiative manage those five or so fields. When you have that, you can then share that out again with the right stakeholders and ensure that they’re being updated with the information they need.

When it comes to determining what fields are needed, that really comes from what’s the noise that you’re hearing? What are people constantly just asking you for? This is where, as an operations manager, you’re trying to figure out, how can I simplify or optimize this process? I’m constantly being asked for a status update on this. That means that I, as an operations manager or a program manager, have to go out to the PMs and knock on their door again and ask for all this information, on a weekly or bi-weekly basis. Those are the types of things that you’ll want to just have standardized as a PDLC deliverable milestone for that use case. So that way, you can just have a single place where you can just direct your PMs and say, hey, it’s that time again, can you just go and update this one view for this one specific use case, and then you get all the information you need.

How Dragonboat’s PDLC Helps Cornerstone Save Time and Increase Efficiency

Camila Souza: That’s awesome. One last question on the PDLC topic: how long did it take you to get the PDLC set up, and then how much work was it that you put in, and how efficient did you become afterward? And the reason I ask that is because I have seen PDLCs being set up that it’s almost… it takes twice as long to put a framework in place and put something to go, and then the value that they ended up getting it is not equipped to the amount of effort they put in. Can you talk to me about your experience? And… and we all got the gist, audience, that Greg is super sharp, he understands, he has his frameworks and process, but, that is an adoption, a framework, and a process they need to put it in place in order to be able to leverage it. How long did it take you? And then, also, how, efficient, more efficient did you become? And what has been the feedback from your team with what you have, set up today?

Greg Shintani: Yeah, great question. I can share an anecdote in terms of efficiency. 2 months ago, my colleague came up to me and said, hey, I need to prepare a status report for this program. It’s a new initiative, and it requires stakeholders from 4 different product domains, and we need to be able to report on it on a weekly basis. That colleague of mine came to me asking, like, can we do anything in Dragonboat? Does this data already exist in Dragonboat? Can we just set up a view or something? Well, no, it didn’t, because we don’t have all these specific custom fields that are… and that was actually the proposal that came up first. Like, let’s just create, like, 5 new fields. Like, no, let’s not. Let’s try to streamline it a little bit more. 

So, it literally took me maybe half an hour max after chatting with this colleague of mine to figure out what were the key things that they were trying to report on, what information they needed to get from PMs, and what information they needed to get out to the leadership. And after coming up with a rough draft, we just, in the backend on Dragonboat, just set up the PDLC fields, literally took, again, no more than a half an hour call.

Normally, as a program manager from a reporting perspective, what we normally would do, I think, is, without Dragonboat, we would just create a spreadsheet. Create a spreadsheet, get a template going, share that spreadsheet out with all the stakeholders, they would have to then go into that spreadsheet, and then they would also have to not just go into the spreadsheet, but they’d have to go into JIRA, or whatever tool that they have all their information in, figure out what it is, go put their updates into that spreadsheet, and then do that every, again, however often that you need to report out. That then takes up an exorbitant amount of time of constantly having to send these status updates to your stakeholders that need to provide the updates, and then just chasing them down to actually do it, whereas once you have it in a standard place, and since they’re already always in Dragonboat doing all their roadmap planning anyway, it makes it that much easier just to ask them to, hey, can you just fill out that one additional thing? It’s this one view, here’s the link.

How AI Is Shaping Decision-Making in Product Portfolio Management at Cornerstone

Camila Souza: That’s awesome, Greg. I appreciate that. We’re going to shift gears again and then jump into the trendy AI train. So everybody is hyped up and looking into ways they can optimize their processes, and what the current tools they are using can enable them to be better, be faster, and leverage the insights they currently have in order to make the decisions. Can you talk to me a little bit more about… I know Cornerstone is looking at all its tools, evaluating and figuring out how can you enhance or make it the current process of manual tasks, leveraging the AI component of it. How do you see AI shaping decision-making in the product portfolio management over time?

Greg Shintani: Yeah, I think AI is a hot topic for everyone right now. And specifically for Cornerstone, as well as just portfolio planning in general, I would say the main area I see AI coming into play is really being able to aggregate and synthesize all these data inputs. We have information coming from the actual epics that are being created, we have information like feedback coming in from our customers. We have information on, even just how we deliver things. When it comes to AI and portfolio planning specifically, AI will really play a big part when it comes to resource allocation and making recommendations based on a lot of that data. 

We talked about PI planning and our processes at Cornerstone. We collect a lot of information over time. We get inputs on every single epic as to how much effort that was originally estimated to be associated with whatever the scope was, how much the PMs actually commit to that specific epic for what they’re planning for the release, as well as what the actual capacity was once that item has been fully executed and delivered. With all that data, you can then really understand these trends over time, these patterns. Like, is this one specific pod, for example, constantly delivering beyond the scope of what they originally set out for their total capacity? What recommendations can we give to that pod to help them streamline their planning in the future? Are we able to unlock more capacity because, actually, this pod is specifically able to deliver a lot more than they think they can based on the estimations that they’ve been giving every single release?

And then, ultimately, long-term, does those resources, from an organization perspective, can we essentially aggregate those additional resources, or make recommendations of how we structure our organization to optimize that further. So it’s helping inform decisions, even from a corp structure of how your pods are working together, what resources are being invested into what portfolios, as well as just overall velocity as you continue to do your planning and execution, release over release.

How Cornerstone Connects Dragonboat, Jira, and UserVoice Across the PDLC and Plans to Improve the Flow of Insights, Planning, and Execution with AI

Camila Souza: That’s awesome, no, absolutely. A follow-up question here that I have for you. Cornerstone has done a great job connecting tools like Dragonboat, Jira, UserVoice, Tableau, and any other tools within the ecosystem. Within the same AI topic, but looking ahead, what opportunities do you see to strengthen further the connection between customer insights, strategic planning, and execution within the ecosystem that you currently have?

Greg Shintani: Maybe just to outline the way that we’ve set things up, we are currently using 3 main tools in our PDLC. First and foremost, we have Jira. That’s our execution tool, and the primary end users for that tool is engineering. We’ve also added Dragonboat into our stack, and the primary end users are our PMs, and that’s where all of the roadmap planning goes into play. We do our capacity planning and everything in Dragonboat. And then we’ve also added a third tool called UserVoice, that is essentially a customer feedback aggregation tool. It has a front end that we expose to customers, where they can submit, you know, ideas or feedback specifically about our products, and then it has a back end where product managers can log in and then be able to review all that feedback, and then ascertain whether or not they do want to promote it to the roadmap. As we’ve set up all of these different tools, and we’ve set up these different, very specific use cases, and aligned it to our PDLC, we’ve just been constantly trying to figure out how can we optimize and streamline the flows between them. And tying in the AI topic, one of the things that we’re looking at is how can we streamline information that’s being aggregated in one system, and then making sure that it’s flowed through all the way from start to finish. The reason why we’ve set up each of these tools really has to do with what PDLC phases that we’re aligning them to, and then the stakeholders that use them.

​​Why Dragonboat Is a Must-Have (Not Just Nice-to-Have) for Managing a Complex Product Portfolio Like Cornerstone’s

Camila Souza: That’s awesome, and it makes sense. We are all looking for streamlining, the fasting side, to make us better, make us more competitive. I’m gonna prompt you with another question.You talked about Jira, you talked about UserVoice, and how those tools are connected to give you that workflow that’s very streamlined. So I need to ask, why is a tool like Dragonnoat a must-have versus a nice-to-have, when you have multiple teams delivering in Jira at the project level for a complex product portfolio like Cornerstone’s?

Greg Shintani: Great question. I’ll segment my answer into two parts. The first is really what was the impetus for us as an organization, even looking for a tool like Dragonboat. We are a large enterprise company, and we’ve made multiple acquisitions, especially in the past couple of years. And every company has Jira, which means that every acquisition that we get has its own Jira instance. And so we had, I would say, at least 5 different Jira instances that we were working across, and that makes it really difficult for just product management. You have information that lives in one instance, and someone else doesn’t have access to that instance, so then you have to create a duplicate ticket over in the other instance, and so it’s really a nightmare to manage. It took time for us to really figure out a game plan of how we could migrate all of them together, and I’ll talk about that in a second, but with Dragonboat, we were able to actually integrate every single one of our Jira instances into Dragonboat as essentially an overlay. All of the epics and information that all of these disparate teams were working across different Jira instances were then able to come together in Dragonboat, and then access, manage, and collaborate together in a single tool, and have visibility to everything. So you could have these dependencies on these items from one Jira instance and connect it to another one in Dragonboat, and then manage your planning that way, as opposed to then again, just having all these access issues with all these complex tools and systems. So that’s the first piece, just being able to simplify how you operate. And that might not be a problem for everyone; smaller companies will not have more than one Jira instance, not an issue.

We have since, you know, and to the kudos of our great engineering operations team, they’ve done a great job this year of aggregating all of our Jira instances, migrating them all into a single Jira instance. They’ve standardized all of the fields across all of them into essentially having one standardized template for every single project that we work across. And so that question remains, why do we still need Dragonboat if we just have that one instance, can’t we just do everything in Jira? Well, I think where it comes into play a lot still is the organization of, even in that one Jira instance, we still have dozens of projects. And those projects, you’ll have one product portfolio that is actually spread across 6 different projects. And then you’ll have another product portfolio that somewhat overlaps with some of those projects as well. And so, even with a JQL query of, I just want to see all the epics associated with this one Jira project, you’re not really able to then get the exact extract that you need to see everything related to what you’re specifically trying to ask about. With Dragonboat, there’s a very specific hierarchy you can set up. It really depends on how you structure it for your organization, but you can set all your roadmap values, your top-level portfolio items, and then underneath that, you can then set up specific product families. Those can be Jira project agnostic. You can have different epics tied to each one of those, and so then when your product leaders want to do any sort of reporting, or they want to do any sort of analysis on what their teams are actually working on, you don’t then have to come up with these really convoluted, very complex Jira queries, or come up with a special tagging protocol in Jira, or labeling convention that you have to just hope that your teams remember what the label was for whatever you’re trying to put together, and really just visualize it all very seamlessly in Dragonboat. So, even still with one, just a single, simple setup with one instance of Jira, you’re still able to have that additional reporting and organizational value that Dragonboat has.

How Dragonboat Helps Leadership Balance Innovation vs. Maintenance — and Which Data Points Drive Strategic Decisions

Camila Souza: That’s a great insight, and go into my next question for you, which is really related to empowering leadership, to visualize the balance between the innovation and maintenance, and then most importantly, I think, like, when you are doing these roll-up reports and setting up your views, we always need to communicate with leadership where things are and how we are moving along. I guess my question to you when it comes to the data itself is, what data points have been most useful, and how do you drive strategic conversations enabling your leadership team with that information?

Greg Shintani: On the product ops team, we get asked questions all the time from leadership. Essentially, your leadership will be the ones that are setting the direction for your long-term roadmaps. They’ll be setting the initiatives and the themes that are of utmost importance for your company mission. In order to make sure that we can get them the information they’re looking for, the general thing that they’re mostly looking for is, how can I make sure that what we are communicating to our organizations is actually being executed on? What goes into the release? How do we make sure that that’s actually aligning to these concrete themes and initiatives that we have are prioritizing and preaching in the organization?

The traditional way, again, pre-Dragonboat for us was, each of the VPs in our organization that owned all their respective portfolios, they would just go out into JIRA, do an export, put together a spreadsheet, send it out all to all of the PMs that report into them, like, hey, my boss is asking for this information, can you make sure that this is, like, everything, right? And then you just get a spreadsheet with all these line items of epics, like, great, okay, so you can share that with your exec leadership, but I don’t really feel like that’s necessarily what they’re looking for, right? They have to then do another level of analysis of, like, okay, well, does this actually… great, I understand what this epic title is, but does this actually align to what we’re trying to accomplish?

And so, when we have done our PI planning, we have also established, capacity allocation values. So, every PM, we ask to specify specifically, does this Epic align to a new innovation, or does it align to tech debt? And so, you can have labels for those as well in Jira, or you can have labels for them in a different custom field in Dragonboat, but there’s a lot of different things that you can set up to be able to then, report off of with that hierarchy I shared earlier, right? You have specific product portfolio, or product roadmap and product family, and then you can look at the actual breakdown of how much capacity is being allocated to tech debt just for this one specific portfolio. And that’s ultimately what we get asked about from leadership all the time, what percentage is being dedicated to new innovation associated with this one product or with this one initiative? If I use an analogy to nutrition, they’re looking for the macronutrients. They want the breakdown of  the protein, the carbohydrates, and the fats. They don’t care about how much calcium you’re getting on a sprint-to-sprint basis, right? So in order to report off of that, you can then just leverage how you set things up in Dragonboat to really just very quickly visualize that and structure it based on how your organization is set up.

What an Ideal Leadership Report in Dragonboat Looks Like and Which Metrics It Includes

Camila Souza: Yeah, absolutely. I think we’re running out of time here, but I have a few more questions, and we need to get to Q&A. So, on that topic, if you could design the ideal leadership focus report in Dragonboat, what would it look like, and what metrics would you include?

Greg Shintani: Yeah, again, the primary thing I think we get asked about from leadership is, capacity, and resource allocation, and also, the total capacities for all of the pods. They do like to see how much capacity do we have release over release. And sometimes there are changes that the engineering org makes that is not fully visible to the product org until we actually do some of this analysis, and so they can see over time how much capacity is being dedicated to each of their respective portfolios, and then having those kind of harder conversations with leadership to figure out, like, “do we need to actually invest more resources into portfolio A versus Portfolio B?” So I definitely would set up reporting to be able to easily visualize all of that.

Where Cornerstone Has Seen the Biggest Efficiency Gains Since Adopting Dragonboat

Camila Souza: Absolutely, that’s great insight, Greg. All right, I want to shift gears to some of the Q&A, if you don’t mind. We have a couple of minutes left here. Okay, so here is the first question we got from our audience. If you look back since adopting Dragonboat, where do you see the biggest improvement in efficiency, and what part of your process feels most streamlined now, compared to before?

Greg Shintani: Yeah, great question. I think in terms of efficiency and where we’ve seen the biggest improvement is really our say-do ratio. We’re able to, as we continue to do PI planning, release over release, and we have these really defined processes, we’re able to really hold ourselves accountable to what we’re able to commit to, and when things get disrupted in the middle of the release, we’re able to look back at it and then make better adjustments for the next release. Through this process, we actually unlocked across our entire organization, when we analyzed the data over the first year, we actually ended up unlocking roughly, like, 2,000 story points that we didn’t have before. And those weren’t 2,000 story points worth of effort that are from new resources, that’s literally just from our existing pods, because they’ve gotten that much better at estimation.

Key Challenges in Managing Multiple Portfolios After Acquisitions and How Dragonboat Helps

Camila Souza: That’s awesome. Thank you, Greg. And then, one more here that we have is, what are some key challenges you have faced managing multiple portfolios after Cornerstone’s acquisition activity, and how has Dragonboat supported this process?

Greg Shintani: Yeah, I think, with any M&A, you’re going to run into different cultures, different processes, even mindsets, right? Some of the companies that we’ve acquired have been smaller; they’re used to being a lot more agile, they’re used to not following all these processes. But then, when you can understand, when they come in, what we try to do is we understand what’s the current process today, and then how can we kind of phase out or roll out the process that we’ve established in somewhat of a phased approach for them, and so then we try to do the best we can to align any of the fields that we’ve standardized to the fields that they already have, and then, again, just roll it out in small pieces at a time. We don’t force them to immediately just adopt these new PI planning processes that we have. We definitely take sometimes even a year to give them some ramp-up time to be able to understand what our process is, sit in on the planning sessions for the other portfolios, and really understand how the different puzzle pieces fit together.

Closing Remarks

Camila Souza: Awesome. I think we are right on time now, Greg, it has been a pleasure. Thank you again for sharing your story and Dragonboat’s journey. Thank you all for joining today’s session in our Product Operating Excellence Mini Series. 

If Greg’s story gave you ideas for your own organization, and you want to see how Dragonboat can help your team strategize and deliver at AI speed, please check out dragonboat.io. And if you have more questions for Greg, please send us. We’ll be happy to send those to him, and then we can certainly get you answers, or you can just get in touch with Greg on LinkedIn. 

So, Greg, thank you, thank you so much. That’s been a pleasure. I know there is so much more that we haven’t had a chance to touch, so I’m hoping that I can invite you over once the new year is around. So, any final words, Greg, before we wrap up?

Greg Shintani: Yeah, just thank you so much, Camilla, and thank you to the Dragonboat team for having me. It was a pleasure also just speaking with everyone and sharing my experiences, so hopefully some of what I’ve gone through can be translatable to your guys’ work. Appreciate it.

Camila Souza: Thank you, Greg. Have a good one. Bye!

Reference

• Cornerstone, a global leader in workforce agility, learning, and talent management solutions.
• UserVoice
• Jira