After more than 30 ServiceNow implementations — some lasting just a few weeks, others stretching over a year — one thing has always been clear to me:
the success of a ServiceNow project rarely comes down to the technical team, the project manager, or even the platform itself.
It comes down to the Product Owner.
And as we’ve discussed in previous blogs, that role can make or break a project.
In the first post, we talked about how the Product Owner is the most important role in a ServiceNow implementation.
In the second, we explored why time and availability are absolutely critical.
Now that you’ve created that time and space to focus on the project, it’s time to prepare — to walk into the implementation ready to lead, decide, and deliver.
This post is all about preparation. And yes it is a long one as there is a lot we need to prepare for 😁!
From my experience, there are three main components every Product Owner should focus on before the first workshop begins:
-
Kicking off the Value Management exercise
-
Technical preparation
-
Strategy and planning
And, as always, I’ll share how Engagement Managers can help you through this phase.
1. Kicking Off the Value Management Exercise
Every ServiceNow project starts with a promise — to deliver value. But before you draft a single story or start configuring anything, you need to be clear on what value means for your organisation.
That starts with the business case.
The business case
It’s easy to treat the business case as a document that just helped get the project funded — but it’s actually your foundation. Reviewing it carefully helps create alignment between everyone involved and makes sure the whole team understands the why behind what you’re about to deliver.
Now, I’m pretty sure ServiceNow has already been working with you through this phase. Our teams are experts in helping customers define value, and we’re often involved in building the business case. But if that’s not the case — no worries. We just need to make sure we talk to the right people and get clear on what we’re trying to achieve.
This sounds simple and obvious, but I can guarantee you the business case is most of the time seen as a boring document — something discussed only during the drafting phase and then forgotten. Product Owner, this is your responsibility. You need to take it back, review it, and make sure everyone is aligned. Get your Executive Sponsor and Business Owners on board and ensure everyone agrees on the value we’re aiming to achieve.
The goal here is simple: bring the key people together, confirm the main goals and assumptions, and make sure everyone agrees on what value looks like.
To keep it simple, these are my three main alignment groups — there may be other stakeholders involved, but to me these are the main ones. Not always more groups or people necessarily mean better outcomes. We need to sit down and look at the stakeholder list and decide who really needs to be involved in this phase.
-
The Business Owner(s) – They own the process or service vision, goals, and objectives. They also own the problem you’re solving and will inherit the solution once it’s live. The Business Owner defines what success looks like once the solution is operational.
-
The Executive Sponsor – They bring the strategic view. Their focus is on how ServiceNow fits into the bigger picture of your organisation — and they contribute to define what value to the business really means.
-
The Platform Owner – They bring the technical perspective. They understand the platform’s capabilities, dependencies, and limits, and they validate the assumptions made in the business case.
These three groups are the heart of your value alignment. Make sure they’re all on the same page about the purpose, priorities, and assumptions behind the project.
In many implementations, this is where things start to fall apart. The team rushes into delivery, only to realise halfway through that everyone has a different idea of what “success” means. Taking the time up front to align on value avoids that problem — and sets you up for a much smoother project.
Defining the Value Blueprint
Once everyone agrees on the why, the next step is to make that “why” measurable — by defining your Value Blueprint. This is an important step of our implementation methodology. I am not introducing anything new.
This is where the Product Owner works with key stakeholders — especially the Executive Sponsor and Business Owner(s) — to identify the business objectives and expected outcomes of the implementation.
It’s important to clarify that the Value Blueprint is not the business case. The business case helps justify the project and secure funding, while the Value Blueprint defines how you’ll measure whether that investment is delivering real value. Some of the information from the business case will feed into your Value Blueprint, but this is where things get practical and measurable.
If you’ve been working with a ServiceNow team, I’m pretty sure our Value Management group has already been part of this conversation — helping you define or refine your expected outcomes. But if there isn’t a Value Blueprint yet, or if the existing material looks a bit different, that’s okay. This is the right time to get everyone together and build it properly.
Your Value Blueprint should go beyond high-level goals like “improve productivity” or “reduce costs.” It needs to show exactly how you’ll measure success in a clear and practical way (S.M.A.R.T — Specific, Measurable, Achievable, Relevant, and Time-bound).
A simple Value Blueprint helps keep everyone aligned throughout the project. It connects the implementation work to real business results and keeps decisions focused on what matters most.
It’s also important to remember that the Value Blueprint isn’t a one-off activity. It’s a living document — one that should be reviewed, updated, and endorsed by the Executive Sponsor, Business Owners, and other key stakeholders. It might evolve as the project progresses, but any changes must be assessed carefully. Every adjustment should be considered in terms of its impact on the project’s goals, scope, and overall value.
The Value Blueprint is your north star during implementation. When questions or trade-offs arise — and they always do — this is the document you come back to for direction.
When defining baselines and targets, use real data wherever possible, not assumptions. Even if the numbers aren’t perfect, they’ll give you a realistic picture of where you’re starting from and how far you want to go. That data-driven approach makes discussions with your stakeholders — especially sponsors and business owners — far more meaningful.
Here’s a simple way to build your Value Blueprint:
| Question | What it means |
|---|---|
| How does the organisation define success? | What business results do you need to call this project a success? |
| What are your objectives? | What specific business goals are you trying to achieve with ServiceNow? |
| What operational outcomes support these objectives? | How will ServiceNow help reach those goals day-to-day? |
| How do you measure success? | What metrics will show that you’re achieving those outcomes? |
| What’s your baseline? | Where are you today? |
| What’s your target? | What improvement do you expect one year after go-live? (for example) |
Ideally, your Value Blueprint also ties back to your organisation’s strategic objectives, not just process-level goals. This is where Engagement Managers can also support you — by facilitating these conversations, helping you structure the discussion, and making sure what you define at this stage connects to the bigger business picture.
And finally, your Value Blueprint isn’t just a tool for preparation — it’s also a key input for the next phase of your journey. You’ll reuse it when defining goals and objectives, ensuring a seamless link between the value you’ve promised and the strategy you’re about to build.
When done right, it gives clarity and focus not just to the Product Owner, but to everyone involved in the delivery.
Once the value is defined and everyone’s aligned on what success looks like, it’s time to look at how you’ll get there — starting with your technical preparation.
2. Technical Preparation
Once the value is clear, it’s time to get practical — and that starts with technical preparation.
This is where many Product Owners underestimate the effort needed. You might think preparation is mostly about planning workshops or collecting requirements, but that’s not the case. True preparation starts before the first meeting — by learning, exploring, and understanding both ServiceNow and your own environment.
Learn the Product
Before the project starts, the Product Owner needs to become familiar with the ServiceNow product area being implemented. You don’t have to be a technical expert, but you do need to know what the platform offers and how it’s meant to work.
The best Product Owners I’ve worked with invest time to:
-
Complete Now Learning courses and watch short videos on the specific product (ITSM, ITOM, HRSD, SecOps, etc.).
-
Read through product documentation and release notes to see what’s available out of the box.
-
Explore demo or sandbox environments if possible, to get a feel for how the product behaves.
This is a really important step. At ServiceNow, we move super fast. Most of the time in early workshops is actually spent explaining how ServiceNow works and what each product does. And that’s fine — it’s part of our job. But ideally, I’d love to spend that time confirming your understanding, not explaining everything from scratch. When you already know the basics, the conversations become much richer, faster, and more productive.
Understanding what ServiceNow delivers natively helps you make better decisions later — and start defining in your mind what a Minimum Viable Product (MVP) could look like.
If you understand the out-of-the-box capabilities, you’ll know when to adapt your process and when it makes sense to extend the platform.
Assess the Current Environment
Once you’re familiar with the product, it’s time to look at your current setup.
This might sound obvious, but you’d be surprised how often Product Owners join a project without a clear picture of their current environment. That’s a major risk. If you don’t understand how things work today, it’s nearly impossible to design a better future state.
Start by asking yourself:
-
Are your current processes documented?
-
Do you have existing process maps, roles, and data definitions?
-
What pain points are driving this project?
-
Do you have access to reports or metrics that show where things aren’t working?
If you don’t have this information, that’s okay — and it’s not the Product Owner’s responsibility to create all of it. But it does highlight how much time and effort is involved in building a solid foundation for the project. The earlier you can gather and share this information, the faster the team can move later on.
The goal isn’t to document everything in perfect detail; it’s to make sure everyone has a shared understanding of the starting point. That context will help the implementation team design the right solution and save you countless hours later in workshops.
Build Your Confidence as the Product Expert
The Product Owner is the voice of the business — the person who really understands how things work today and what needs to change. To play that role effectively, you need to be confident in both your product knowledge and your process understanding.
You don’t have to know every technical detail — that’s what the ServiceNow consultants and architects are there for — but you do need to be able to say:
“This is how we work today, and this is where we want to go.”
When you reach that point, the discussions in workshops become faster, clearer, and more productive. You’ll make better decisions, avoid rework, and keep the project on track.
When the technical preparation is done properly, the Product Owner walks into the first workshop ready — ready to lead, to make decisions, and to represent the business confidently.
With the foundation in place, it’s time to move to the next part of preparation: strategy and planning — defining how you’ll turn that value into an actionable roadmap.
3. Strategy and Planning
Once the technical prep is done, it’s time to look at the bigger picture — your strategy and planning.
This is where everything starts to connect: the value you defined, the platform you’re preparing for, and the roadmap that will get you there.
Up to this point, we’ve worked on the business case and built the Value Blueprint, defining the outcomes and success measures. We’ve also done the technical preparation, learning what ServiceNow offers and understanding the current environment. Now it’s time to bring these two worlds together and translate them into a clear vision and set of goals for the implementation.
Some of the content from your Value Blueprint will naturally feed into this step, but the vision goes a level higher — it’s about conceptualising how those outcomes will come to life through the ServiceNow platform. The Value Blueprint focuses on the current situation and the value you want to achieve; the vision is where we start to define how that value will be realised using the capabilities of the product.
Define the Vision and Goals
Every successful implementation starts with a clear vision.
That vision should answer one simple question: What are we trying to achieve with this ServiceNow project?
For some organisations, it’s about efficiency — reducing manual work and automating processes.
For others, it’s about transparency, compliance, or improving the employee or customer experience.
Whatever it is, the Product Owner plays a critical role in making sure the project vision and goals are not just clear, but also shared and understood by everyone involved.
This is also the time to review your business case and Value Blueprint again and make sure your vision directly links to the outcomes and targets you’ve already defined. It’s about keeping the “why” front and centre as you move into delivery.
I know I may be over-cooking it at this point, but let’s clarify before we move to the next step: the vision is your dream — it usually looks many years ahead — while the goals are the steps that move you toward that vision.
From Goals to Roadmap
Once the goals are clear, you can start translating them into a roadmap.
This is where the Strategic Portfolio Management (SPM) suite — and in particular, the Strategic Planning Workspace (SPW) — can really help.
Only a couple of years ago, I started exploring how these capabilities can support every single project from this point of view. Since then, I’ve used them on several occasions — and even ran an advisory engagement with one of our Customers where we put SPW into practice. I was genuinely impressed.
I honestly believe this is the piece that’s often missing in most implementations today — the part that connects goals to delivery: from goals → to targets → to roadmaps → to epics and stories.
That connection is absolutely key.
It’s worth noting that value management has always been part of the conversation in implementations. But I’ve personally noticed that over the past two or three years, there’s been a much stronger focus on actually showing the results — linking outcomes to objectives and proving that the implementation delivers measurable value.
When I started writing this article, I actually did a bit of research to see if this was just my impression or something that others had also observed. And it turns out, it really is a thing. I came across an interesting article from McKinsey & Company, written around 2020, that talks about this shift in mindset.
I think this is part of a post-COVID behaviour — organisations have become more careful about how they invest and much more interested in understanding the return on that investment. It’s not the purpose of this article to go deep into that, but it’s something I’ve seen consistently across Customers: a much greater focus on connecting value to goals, and on making sure every project outcome clearly contributes to business objectives.
If you’re part of a ServiceNow implementation, you can — and should — drink our own champagne. SPW is one of the best tools available to drive that link between strategy and execution. It helps ensure that everything we do during implementation has a purpose, and that every story or epic ties back to the original goals and objectives.
If for some reason you can’t use SPW, that’s okay — you can still use other methods to define the roadmap, but the result will likely be less efficient and more manual.
Now, just to be clear — I’m not trying to promote SPW. This isn’t a sales pitch 😅. But I genuinely believe SPW fills one of the biggest gaps in today’s implementations. What makes it so powerful is how it allows you to show value instantly, without long, manual analyses at the end. It lets you trace every user story back to a goal, so you can see — in real time — how each piece of work contributes to the bigger picture.
And just as importantly, it helps teams stay focused during delivery. When something new is suggested or added mid-project, SPW makes it easy to check: Does this align with our goals? If not, we can park it. That focus saves time, effort, and budget — and ensures the project always stays centred on what really matters.
What makes SPW so powerful is how it keeps value and goals visible throughout the project.
In too many implementations, we talk about value at the beginning — if we’re lucky — and then once delivery starts, we go straight into “implementation mode.” Requirements take over, sprints move fast, and we lose sight of why we’re doing what we’re doing.
Back in the waterfall days, we used to have things like traceability matrices to connect requirements to objectives. In agile, we tend to lose that visibility. SPW brings it back — but in a modern, agile way. It allows us to maintain that traceability all the way from high-level goals down to individual stories and epics.
And the beauty of it is that at the end of the project — when we talk about value realisation — it’s all there.
You can clearly show how every piece of work you’ve delivered links back to the goals and objectives you set at the very beginning.
That’s not just powerful — it’s incredibly valuable.
Prioritise and Engage Key Stakeholders
Strategy and planning are not solo activities. The Product Owner’s strength lies in engaging stakeholders early and often.
This includes your Business Owner, Executive Sponsor, Platform Owner, and any other subject matter experts who will shape decisions during the project.
Use this stage to:
-
Validate the goals and priorities you’ve set.
-
Discuss what success means to each stakeholder group.
-
Confirm that everyone agrees on what “value” looks like and how it will be measured.
Involving people early avoids surprises later. It also builds trust — and trust is one of the most valuable currencies in any implementation.
When you combine value alignment, technical preparation, and strategic planning, you walk into the project with a clear head, a solid foundation, and a shared vision.
You’re not just reacting to what’s being built — you’re leading it with purpose.
How Engagement Managers Can Help
You’ve probably heard me say this before: ServiceNow Engagement Managers are people experts. We support you, guide you, and coach you in every phase of the implementation.
And to be clear — coaching means being practical. We’re not advisors who drop a deck and disappear. We work with you. We’re partners, another set of hands on the project, helping you do the work step by step.
Here’s how we help during preparation:
-
Plan preparation and training (with real assets)
We don’t just point you to courses — we get you access to the right resources and the right people: Now Learning paths, frameworks, checklists, reusable artefacts from similar engagements and amazing ServiceNow training consultants. We help you sequence the learning so it fits your product area and project timeline. -
Set up the Value Blueprint
This isn’t new theory — it’s part of our ServiceNow six-phases implementation methodology We know what to focus on, what details matter, and where to stop (it’s easy to overcook this). We keep it simple and usable by the whole team. -
Clarify roles and responsibilities
We map who does what, when: Product Owner, Business Owner, Sponsor, Platform Owner, SMEs, and the delivery team. We make clear that the Product Owner doesn’t do everything. We show where to put your effort (decisions, prioritisation, stakeholder alignment) and what the team covers. -
Build the Goals → Roadmap → Work framework
Let's “drink our own champagne”: set this up in Strategic Planning Workspace (part of SPM). We connect goals and targets to build roadmaps, then to epics and stories, so every piece of work ties back to value — and value realisation analysis is easy at the end.
In short: we’re not just consultants; we’re your partner in the work — practical, hands-on, and focused on what will make the biggest impact before day one.
Looking Ahead
If you’ve made it this far, you’re already ahead of the game. Most projects rush straight into delivery without investing the time to prepare properly — and that’s usually where things start to unravel.
Preparation isn’t just about ticking boxes or finishing a checklist. It’s about building the right mindset, getting the right people involved, and making sure you’re ready to lead when the project starts.
By kicking off your value management exercise, preparing technically, and setting a clear strategy, you’re not just setting up a smoother project — you’re setting yourself up to be an effective Product Owner.
I know it sounds like a lot of work — and it is. But trust me, the preparation you do now is what separates a smooth implementation from a painful one.
Because remember:
Great ownership starts with you.
