Successful Digital Transformation Through a Product Management Organization

DACE CAMPBELL: Welcome to Successful Digital Transformation Through a Product Management Organization. My name is Dace Campbell and with me is Anna Lee.

The construction industry is filled with waste. We are responsible for half of the global waste contributing to climate change and more than half of the activities we undertake to develop the built environment are wasteful. Many forward-thinking contractors and manufacturers are investing in digitizing their processes to drive out this waste.

However, all too often technologists are too far removed from business operations to effectively manage the investment in new tools and products to have a successful impact on their business. This disconnect can lead to veering towards one extreme or the other of a push-pull spectrum.

That is, the business operations pulls technologists in the direction they think is best for their specific needs at the risk of executing on siloed short-term thinking, barely moving the needle forward, and implementing redundant piecemeal solutions.

On the other hand, technologists risk pushing emerging technology into business operations without addressing real world needs, causing an organization to chase shiny pennies that seem attractive at first but lack buy-in or staying power as a valid long-term solution.

At McKinstry, we've invested in a product management organization, or PDMO, as a corporate service unit specifically dedicated to researching, developing, implementing, and managing our business technology. PDMO acts in partnership with our organization, but we leverage a product management philosophy to provide a structured framework for innovation that aims to strike the right balance between this push and this pull.

Product management is its own discipline, not necessarily specific to software or hardware, agnostic to solving problems for any particular industry. It's a perfect fit for McKinstry as a full-service solution provider across the facility lifecycle, including design, fabrication, construction, and operations. Product management gives us a common vocabulary, breaking down silos and supporting the convergence between construction and manufacturing industries.

Think back to the last time you used a new tool to accomplish an old task. What drove your decision to try that new tool? How do you use the right one? How did you decide which features or functions were important? How did you how do you know you were successful using it?

Product management allows us to focus on the right solution based on business value and measurable outcomes because the tools we build or buy are just a means to an end. When you go to the home improvement store to shop for a drill, you don't want to buy a drill. You just want to make holes.

ANNA LEE: And to figure out how to make better holes and not get fixated on what tool to buy, at McKinstry we follow a product lifecycle consisting of seven phases, each with their own phase gates and milestones.

Before I get into more about the product lifecycle, I want to first define what product means at McKinstry. We defined product as a tool or technology solution that solves a business problem. And to solve that business problem, we use and follow the PDMO product lifecycle. Sell, develop, engineer and manufacture, build, transition, operate, and discontinue.

This framework guides us to ensure the products we are working on are valuable, have clear objectives, measurable success metrics, and a clear problem we are trying to solve. Throughout this talk, I will be taking you through each of these phases in more detail, highlighting the develop and operate phase, which I believe are most crucial phases to complete and be thorough and to implement a successful product.

Now throughout this talk, I want you to keep in mind that this product lifecycle is just a framework and not a step by step guide for each initiative we work on. Not all our initiatives will start right at the sell phase and end at the discontinue phase. Some will start at the develop phase. Some will be in the build stage but go back to develop stage to gather more information. So with that in mind, let's begin.

The first phase of the product life cycle is the sell phase. This is where we identify the improvement, prioritize, perform a return on investment, and build the business case. First step is prioritization of initiatives. These initiatives can come from technology opportunities, feedback and pain points we hear from listening to employees, or strategic plans.

And to prioritize these initiatives, PDMO holds a one-day workshop with executives where we evaluate its ease or feasibility and its value and importance to the company. During the workshop we discuss where each initiative lands in this graph. This workshop gives PDMO a good understanding and perspective on what's important to the business units and is critical for us to setting up our year roadmap.

For more information on how to implement this at your company, make sure to check out Dace's theater talk called "Driving wastes out of your industry-- a new approach from McKinstry," where he goes in depth on how you can implement your own workshop using this process.

Once we'd identified and prioritized, we build the business case to get approval for the product. This consists of determining the return on investment and the strategic or operational value, your product vision, and the cost and/or savings of this effort. This will help build your budget and your case on why we should work on this initiative.

Really take this time to conduct your conceptual ROI and sell its importance and the vision. PDMO aims to prescribe real dollar values at this stage so business leaders have a clear understanding of what they're getting out of solving the problem.

As you complete your business case, you'll have collected enough information to scope out the project and a high-level view of why this initiative is valuable and how the money will be spent. Once your case is complete, present it to the right audience, whether that be an executive or whoever will be sponsoring this initiative. The phase gate in this cell phase is to get your business case approved.

Congratulations on getting your business case approved. Now onto my favorite phase, the develop/discover. I want to spend a little bit more time on this phase as I believe it is one of the most crucial phases for your product to be successful. This phase is where we get to explore the initiative or the idea in more detail by conducting discovery interviews, setting up your project governance, and creating your project charter.

Why is this phase so important? To build a successful product, we need to deeply understand our customers' needs and goals. Typically as a product manager, the problems I am trying to solve are rarely my own, nor will my day to day be impacted with the implementation of this product. So to understand and put our headspace into the customers that will be directly impacted, we need to get to know them, their role, and understand their pain point.

Conducting successful and thorough discovery will significantly improve the probability that we're building the right product the right way or sometimes making an existing product more functional and easier to use.

In the construction industry, we know that the relationships we have with our contractors, our owners, engineers, and architects can really determine the success of the project. Going and talking to your customer rather than making assumptions really builds that trust and loyalty between you as the product manager and your customer.

So who should you talk to and build relationships with for your product? At McKinstry, PDMO's customers are all internal. There are typically three customers types that we should be interviewing during this phase-- the users, stakeholders, and the maintainers.

The users are people who will be directly interacting with the product or the system. These can be your project managers, your field crew, engineers, or all. Stakeholders are people who depend on the results of the system, but maybe don't use it directly.

Your maintainers are responsible for the installation, the setup, the upgrade, and the maintenance of the product while it is in use. They won't directly be using the product, but will need to understand how it is being used to ensure the product fits into the company's tech framework.

For example, an initiative PDMO internally developed and implemented was a field daily report application. This application digitized field daily reporting process. Going back to three customers types, in this case, the users were the field crews that were using the product daily and were directly impacted with this product.

The stakeholders were the project managers, the safety team, and the field executives that wanted to use the data we can now collect to analyze trends and identify risks. Maintainers were IT team and our internal software engineer who developed the product and fixed bugs.

Once you've identified these customer types, it's time to do some interviews to discover the root cause or the pain point. Well, what if it's your first time conducting a discovery interview? Let me share some tips on how to be best prepared and have a successful discovery interview.

Have a beginner's mindset, even if you've already done the ROI on this initiative. Maybe you've read about your customers role or maybe you've watched some videos about their role and make assumptions on their pain points. Regardless of how knowledgeable you think you are about this, still have a beginner's mindset. Question everything. Be truly curious. Find patterns in what they are saying and really listen.

Ask the right questions. Before you go into your interview, just like any meeting you lead, go in with a plan on what you want to ask and what you want to know from this interview. Some examples of questions I ask are how often do you do x, y, and z; when do you do x, y, and z; describe what a good workday looks like; what about a bad workday?

If you are truly curious and genuine people will want to explain more and teach you about their role which lays the foundation for understanding the root cause of their problem. Lastly, ask to record your meeting. And if it's in person, have a note taker with you. You want this discovery interview to feel like a conversation and not a questionnaire, so focus on your customer and not on trying to take the nodes.

So you've prepared your questions, have the right mindset, and are ready to start the interview. In the first couple of minutes of your interview, if this is the first time you're meeting them, build a rapport with them. Ask about their weekend or try finding something to connect on them with. This initial connection you build, even if it's short, could help your customers feel more relaxed, comfortable, and unknowingly more willing to share and talk more.

Once you've chatted a little bit begin with the what, your concrete observations. What are they doing? What is their role? Then move on to how, the understanding. How are they doing what they said they are doing? Look for cues in their tone or voice when they talk about certain things versus others. Dig a little deeper in areas where you feel they want to expand a little bit more on.

Lastly, the why, the interpret. Why is this person doing what they are doing? Build empathy for who they are and what is important to them in their role. Look for inconsistencies between what they are saying and the why. Question those inconsistencies.

As a product manager, I typically do not have direct authority so I need to lead through influence. This influence has created through relationships, and I believe relationships are created on trust. Make your customers feel heard. , Sure interviewing leaders is important to understand where the organization strategy lays, but invest time with the actual users and really understand their pain points.

And don't limit yourself to an interview. Ask to shadow them at their job site or in the office and invest time in developing that relationship and building that trust.

I want to share an example of where we didn't do our due diligence during discovery interviews. For one of our initiatives to digitize pre-test plans, we conducted interviews with the stakeholders, meeting safety directors and those who would benefit from the collected data, but we skipped over conducting interviews with our users.

We didn't take time to ask and listen to the users of this product, how it would affect their day to day, and our users' pain points with their current process. Because we missed this critical step in this phase, we had an immense amount of organizational waste by spending time to develop a product that was shut down when we demoed it to the users. So to avoid this happening, make sure to invest time and talk to all three customer types and listen.

From these discovery interviews, you will hopefully have enough information to have a clear sense of the customer problem and clearly be able to explain what problem you're trying to solve and refine the scope of this initiative. Throughout these discovery interviews, you'll start to understand key players and have enough information to set up project governance.

At McKinstry, our project governance consists of an executive sponsor who provides executive guidance and support, a project sponsor who understands and guides business process changes, a steering committee that is comprised of key stakeholders and impacted business leaders who makes the final go-live and key direction decisions.

A core team typically involving a maintainer customer type and process owners and provides the communication link between teams and key stakeholders. This team facilitates project activities and provides expert input to process and decisions. Your subject matter experts effectively represents the cross-section of user community and groups impacted. These experts will help with performing user acceptance testing, serves as advocates of change, and can assist in training other users.

As a product manager, my role is at the intersection. The product manager works with all of these teams to develop and deliver plans that include all work streams including technology and training. You want to listen to your executive sponsor, your steering committee, work with your core team, and consult with your subject matter experts.

And throughout not only this phase but throughout the whole lifecycle, it is very important to have regular check points and communication with your steering committee and your core team. The cadence of these meetings could depend on the complexity of the product, but the typical cadence I like to have are monthly check ins with my steering committee and weekly meetings with my core team.

With this cadence, regardless of whether the product has made significant progress or not, it reduces the risk of your product going a different direction than of the business needs. At this point, you've conducted discovery interviews and set up your project governance.

From here we want to create a product charter. At McKinstry, we break down the product charter into four main sections-- where are we today, where do we want to be, how do we get there, and how do we measure success.

Starting with where we are today, here you want to identify your problem or pain that you've collected during discovery interviews, its impact, and the business value of that pain. Go back to the ROI you've conducted in the sell phase to refine them using this information you've collected from your discovery.

Where do we want to be? Think about your goals and objectives. What does "done" mean to you and your team? How we get there is your scope and approach. What is your plan look like? Are they broken out into phases? What is your resource plan look like? Who will be involved and how much time are you asking from them?

And lastly, one of the most critical, important, and challenging part is how we measure success. Identify and develop success metrics and define them in a way we can measure business improvement or progress towards that outcome. Identifying the correct success metrics is critical and you want to invest time in developing this to compare and measure your current and future state.

Without a thorough and well thought-out product charter, there can and most likely will be a lack of team and executive alignment, a lack of prioritization, leading people to work on things they think are important, and even feeling a lack of accomplishment. To prevent this from happening, invest your time and thoroughly think through an answer-- where are we today, where do we want to be, how do we get there, and how do we measure success.

Another component of the product charter will be your product roadmap. A product roadmap is a powerful tool to describe how a product is likely to grow and help to align stakeholders. The product roadmap will be the guide for everyone to align on how the product will achieve its vision and really shine.

It will contain your long term product vision and your short-term deliverable deliverables, broken up by milestones or phases. This roadmap should show the way to the vision, your dream of the future, your ideal destination that your product aspires to. There are several ways and templates to create a product roadmap, but here are a couple of tips when creating your roadmap.

Have the roadmap be flexible but structured. Have clear milestones or phases and a high overview of the timeline, showing how each deliverable will get your product to your product vision. Work with your identified core team members to make sure you're covering the right scope and for visibility and transparency. This will allow you to stay organized and have clear next steps and be able to scale your efforts logically.

Make sure your roadmap looks clear, clean, and concise. The clearer and more concise your roadmap is with only high-value information, the easier it will be to explain the status of your product to your steering committee. This will ensure long term communication success and help you build trust from your steering committee.

With a good, easy to understand clear roadmap, the easier will be for you and your team to understand what the product stands. Before we move on to the next phase, I want to again emphasize the importance of this phase and the product charter. And we'll be attaching a template McKinstry uses to have a meaningful product charter.

Once you're steering committee has reviewed and approved your charter, you're ready for the next phase in the life cycle-- engineer and manufacture. The engineer and manufacture stage is the planning stage. At this point, you should have your clear problem statement, set up your project governance, and an approved product charter.

Now it's time to plan and collect requirements. Collecting requirements should be done with your core team as you want to make sure to get buy-in from users impacted by this change. With the problem statement in mind, what requirements would solve this problem? At McKinstry, we categorize the list of requirements to three priorities-- your must haves, which are your number one priorities; your should haves, your number two; and could haves as your third priority.

Perform market research to find if there are products already out on the market. Research could take weeks or months as it involves getting product demos from different companies, maybe a couple of product trials, conducting surveys from your core team on their thoughts on the product, and fine-tuning your requirements based on your market research.

If there is a product out on the market that meets all or majority of your requirements, put together an RFP and send out to potential vendors. But after you've done market research, you may realize that building it internally makes more sense.

But regardless of whether you'll integrate an existing product or create your own, it will rarely be an all-build solution or an all-buy solution, but a matter of how you split that percentage of buy and build. Whether you're going to build something, there will be a buy portion, and vice-versa, if you decide to build a product, there will be some build component.

For a product I managed to replace McKinstry's conceptual estimating tool, we performed a build versus buy decision analysis comparing factors such as functional requirements, product ownership, cost, API documentation, and timeline. This is just an example of an analysis that we conducted to think about whether to purchase an off the shelf product and customize it internally or build a custom product from ground up.

Every product may have different factors to compare and its importance, but make sure to have these kinds of decisions with your core team involved. Regardless of which direction your product will go, involve your IT or software team, consult when needed, and keep them informed to set you and your product up for success.

Once your steering committee and core team have approved your product requirements and have committed to procure, it's time to continue to the next phase of the lifecycle-- build. With your approved product requirements and your commitment to procure, it's time to build. If during the build versus buy analysis, your team has decided to purchase an off the shelf product, explore how to customize the product, configure, and integrate it into your company's tech framework.

If internally building, configure, build, and test. Make sure to have regular cadence with your IT or software team. The phase gate in this build phase is deploy the go or no go decision. At McKinstry, we embrace Agile methodology and focus on iterative development.

As a product manager, it's your job to set up regular meeting cadence to track progress of development and keep the line of communication open with your dev team and your stakeholders. At McKinstry, PDMO's bi-weekly engagement and touchpoints with developers are stand ups twice a week, a story time or backlog grouping meeting, and a sprint planning meeting on alternating weeks.

Stand ups are typically only 15 to 30 minutes where we discuss the status and the blockers. Ask questions like what did you do yesterday, what will you do today, and what is blocking your progress.

The story time or backlog grooming session is a chance for business leaders to get updates on their associated products and is an opportunity for them to discuss items in their pipeline that would potentially need a developer as a resource. During this meeting, we'll also review details of the backlog items to be pulled into the sprint planning session the following week.

Sprint planning is to prioritize and reprioritize items in the backlog to plan for a future sprint. A sprint is two weeks long. And as a team, we make sure we are not overpromising nor underpromising to the business. The outcome of this meeting should be an agreement on the work that the team can complete during the next sprint.

These regular touch points in cadence with your developers and stakeholders add another layer of confidence that the product you are building is truly solving your core problem. At the end of this phase, there will be a go or no go decision made with your steering committee to confirm the product is approved to continue on to the transition stage.

Next is the transition phase or the stabilize phase. This is an exciting phase, but one of the more challenging ones in my opinion in the life cycle. This is where you start rolling out your solution, implement, fix remaining bugs and stabilize.

To successfully roll out a new product or process change, I want to refer to the influence model created by McKinsey and Company. This influence model is a practical and proven guide for changing the mindsets and behaviors of employees. And I want to share some parts of the guide we use that McKinstry during this phase-- have an internal advocate, be clear about the why, and training and support.

Have an internal advocate, or role-modeling. Now this internal advocate ideally would already be in your core team and should be clear on the why and the progress of your product. Your internal advocate is key to help communicate and influence key stakeholders that will be impacted by your new product or new process.

This does not have to be the highest-- the person with the highest title in the company nor does it have to be one person. But pick someone or group of people whose strength is to influence. People naturally and unconsciously tend to mimic individuals and groups who surround them. So having your internal advocate or group advocate be the role model and use your new product will help influence others to follow suit.

During implementation, refer back to your discovery interviews and address the information you gathered from the users. To successfully implement change, those impacted will want to understand the why, so remind them of the pain point your solution addresses. Fostering their understanding of the why can inspire them to behave in support of a change.

The final one may be obvious, but can be poorly done or overlooked. At the end of implementation, you want your users to confidently think I have the skills and opportunities to behave in this new way. If there's minimal support and limited or low interactive training, this will leave your customers feeling unsupported and more unwilling to accept your product.

If your company has an operational excellence team, pull them in to help develop SOPs, training videos, and create a training plan. Without a training and implementation plan, it will severely limit your adoption rate and raise frustrations.

For example, in Q4 of 2020, McKinstry rolled out a new shop management platform that significantly changed the way shop crews were managing their work. The shop crew's workflow went from paper to digital and completely changed how they tracked their progress. For successful implementation, the team rolled out training in phases, with training one shop location at a time.

The team had a full-day training session and with a shop and fully supported them with any questions they had to make sure they felt comfortable and in control of this new product. Installing this sense of control and competence can and will naturally push users to put in an active effort to improve.

Having a clear and well thought out implementation plan will minimize the disruption to the business in a live-fire situation.

Continuing forward to the operating phase of the lifecycle, this phase includes the transition to process owner, developing a support model, and revisiting and tracking success metrics. This is where the product manager hands off the product to the process owner or the business unit. At this point, the business unit assumes responsibility of product operation, while the product manager manages the product backlog and the ongoing operation of the technology.

During this phase, make sure to help develop a support model. How does your customer communicate any potential issues with your product? Who should they engage? How should they engage? How do they communicate whether they need more training? Thinking of the process and support plan for your customers during this phase can determine the long-lasting impact of your product.

Once you create this support model, engage and align with your stakeholders. Once the product is handed off to the process center, as the product manager revisit and continually track your success metrics identified on your charter. Note which ones are on track and where we need to make improvements for future integrations and upgrades to the product. Measure metrics and regularly report progress and adjust metrics regularly.

Thinking back to the beginning of this presentation to purchasing a new tool to make holes, base your product success on business outcomes. How many holes are we creating with this new tool? How much faster can we create holes now that we have this new tool? These are the kinds of metrics we want to care about and measure.

The duration of this operate phase will vary depending on your product, but there may come a time to continue-- to start a discussion and to sunset and discontinue the product. Maybe the product has been determined as obsolete or redundant or business changes direction and want to go a different way. This discussion should involve your standing committee and your core team.

If this is the case, the PDMO will create a retirement or replacement plan of the product and communicate with stakeholders in the business.

And that's it. We've made it through our whole product lifecycle. Hopefully at this point, your product is in full swing and successfully implemented in the business unit with a clear support model for your customer.

Following this product lifecycle can seem like just a bunch of hard hurdles to jump over, but it truly minimizes the risk of building or purchasing a solution that doesn't solve the problem and helps connect you and your customers. So the next time your team has an outdated spreadsheet that is just asking for a revamp or replacement, try using our product lifecycle for a successful digital transformation at your company.