Protected: SAP

OUTCOME

In just three months, our S/4HANA Incubation squad turned a maze of siloed feature groups into a single, high-velocity product engine. By embedding three Fortune-500 customers in a “co-innovation loop,” we validated the thorniest finance-and-supply-chain pain points, prototyped modular fixes, and shipped an MVP that cut pilot lead-time in half, slashed critical UX debt to under 4 percent, and secured three net-new adoption commitments before general release. In short: we married human-centered discovery with ruthless scope control to prove that enterprise-grade innovation can move at startup speed—without shipping crappy UX.

 

 

 

 

 

 

 

 

 

 

THE STRATEGY AND WHY

Hybrid Strategy: Even revolutionary change comes in stages. We approach this with a hybrid strategy: building delighter features for targeted business processes as extensions to S/4HANA and building modular services with modern architecture.

OUR CO-INNOVATION APPROACH

• Deep partnerships (3–5 customers / product): Weekly touch-points, real data, real context.
• Dual validation loop:
  • Problem depth—Are we solving the right pain?
  • Solution fit—Does each sprint increment still resonate?
• Standard-product guardrails: Capture every request, but only backlog what benefits all customers.

OUR APPROACH: NO WASTE

No waste—no dead features for users, no wasted sprints for engineers.

The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. The MVP helps you acquire the relevant knowledge and address key risks; the MMP reduces time-to-market, enabling you to launch your product faster.

While our focus at this stage is prepping for the decision to build (lab phase II), the co-innovation journey will continue into the Build Phase

The co-innovation customer journey (Co-innovation Model) is a time where SAP gets to take a deep dive with customers

Unlike prior phases which had workshops that may last 1-5 days, the co-innovation phase is something that spans lab phase II and build duration with multiple touchpoints during a week and with multiple co-innovation customers

Co-innovation model does 2 things-

• Validates these pain points at a deeper level
• Consistently validates the solution we’re building while we’re building it

An important thing to keep in mind is that this is NOT a custom development engagement, we are building towards a standard product. Customers may express all their needs in these sessions, but not all needs will make it into the backlog and or designs of the final solution. This understanding needs to be conveyed upfront, early, and dealt with delicately

PHASE 1: DISCOVERY

Objective:Define a target customer and build a problem hypothesis.

In the discovery phase we set out to define a target user, craft a clear problem hypothesis, and confirm there is real market need. We interviewed buyers and end-users, mapped the current (“as-is”) journey, and logged critical pain points. The reason for doing this first is to avoid building attractive features that solve the wrong problem; every later decision traces back to validated user evidence. Key outputs were a pain-point map, an opportunity canvas, and a draft PRFAQ that captured the product vision in plain language. Outcome: a shared, data-backed understanding of who we serve and which problems merit investment.

We’d start with a concept validation phase, before working on a solutions architecture at Home Depot. Then we’d work on building, testing, and piloting Athena within the Home Depot Ecosystem. Our goal would be to ideally move as fast as possible, hitting a build phase in 3 months if we started today.

Approach for Co-Innovation collaboration- Internal milestones

LAB PHASE I

With the problem statement in hand, Lab Phase I focused on proof-of-problem validation. The team ran fast ideation workshops, built low-fidelity prototypes, and put them in front of real users within days. The why here is risk reduction: before writing a single line of production code we needed to know the concept resonated. Deliverables included clickable sketches and a feasibility heat-map that weighed user value against technical effort. Outcome: a “go / pivot / stop” decision; only concepts scoring high on desirability and feasibility moved forward.

WHY LAB PHASE ?

• Create solutions with a human-centered design approach, ensuring that our designs and decisions are all backed by real end-user feedback (probably the most important point) Access to real end-users, real data, and real complex business models.
• Grow a relationship and trustwith customers. (early adopters)
• It’s de-risking -> optimizes what’s needed in the market.
• Allows us to build in a feasible ways with real data.

WHAT YOUR 4 SPRINTS IN LAB PHASE II COULD LOOK LIKE…

DELIVERABLES FOR FEASIBILITY ASSESSMENT IN LAB PHASE II – EXAMPLE

LAB PHASE II

WE HAVE CO-INNOVATION CUSTOMERS SIGNED UP! WHAT HAPPENS NEXT?

Lab Phase II was our proof-of-concept engine. Over four two-week sprints we iteratively built a high-fidelity prototype and data-ready APIs while meeting weekly with three to five co-innovation customers. Continuous scoring by those customers (1-to-5 impact votes) ensured that only high-value increments survived. The purpose of this stage is twofold: to validate solution fit in real contexts and to secure early-adopter commitment that de-risks later commercial launch. Outputs ranged from sprint demo recordings to a feasibility deck used at the executive demo day. Outcome: time-to-pilot dropped to three months, and we secured purchase intent from two net-new customers.

Common Risks at this phase:

• Customer data is difficult to attain. This leads to a cold start for the product, which can especially pose problems for machine learning based solutions that require training multiple data sets.
• During requirements gathering remembering this will be a standard product and not a custom development project. (deciding which requirements merit the backlog) Counteraction tactic: test with user outside of the customer (3rd party)

BUILD AND VALIDATE PHASE

Once feasibility was clear, we shifted into collaborative development. Designers and engineers worked side-by-side to convert prototypes into a Minimum Marketable Product (MMP) with customer while usability and accessibility tests ran in parallel. We also tackled the notorious “cold-start” risk for machine-learning features by negotiating early data access with customers. The why is to move from promising prototype to shippable, standards-compliant software without accumulating UX or technical debt. Deliverables included WCAG-audited UI, developer-ready design tokens, and a detailed release plan. Outcome: critical-severity UX defects were held below 4 percent at GA—three times better than previous S/4HANA releases.

1. COLLABORATIVE DEVELOPMENT (BUILD)

Empathy Mapping

User Journey Mapping – Definition of As-Is Process

2. BRAINSTORM & ITERATION

FEATURES SCORING BY CUSTOMERS?

How does your workflow change based on the time of day/week/month

INTERNAL DASHBOARD DESIGN EXERCISE

WIREFRAMING PROCESS

PROTOTYPING PROCESS

USER TESTING

DEVELOPER HANDOFF

END2END  ASSETS

SCALE PHASE

The final stage hardened the product for general availability and long-term sustainability. We integrated design tokens into SAP Fiori, automated regression checks, and created an asset library for future teams. The reason for a dedicated scale phase is that enterprise products live for years; investing now prevents exponential maintenance costs later. Key artefacts included an end-to-end accessibility report and a rollout playbook for Customer Success. Outcome: the first three customers transitioned smoothly from pilot to production, and the scalable design system cut future feature lead-time by an estimated 30 percent.

 

ACCESSIBILITY AND PRODUCT DESIGN

“Accessibility deals with individual stories. Everyone has unique abilities and the unique ability to contribute.”

-SAP Software Accessibility

TAKEWAYS

Progressing deliberately from Discovery through Scale let us remove uncertainty in manageable slices—protecting engineers from rework, customers from unmet promises, and the business from wasted investment.

 

WHAT I LEARNED FROM THIS TEAM

• Be of service– You learn from those around you when you are with an open mind and open heart, and you commit to new opportunities by saying yes to things.
• Lead with trust & respect – People will go the extra mile when they know how much you care, and how much you support them.
• Be transparent & vulnerable– Open the curtain to showcase the vision and the why behind decisions, and don’t be afraid to say you don’t have the answers.
• Give people room to fail– The best ideas are created when people know they have the ability to be creative, and they learn from both wins and losses.
• Surprise & delight people – Call, text, email, send cards, remember milestones, and be that leader who asks about the things in a team member’s life. Celebrate success outside of the norm.

EXTERNAL RESOURCES THAT WERE HELPFUL

• Strategic vs Prescriptive feedback, Fabricio Teixeira
• How to Improve Feedback, Braden Kowitz
• The rule of doubt in designMatthew Strom
• Medium’s “Tactical Design Critiques”, Marcin Wichary
• Making the most of design critiques, Zachary Pfriem
• Share & Care at EightShapes,Nathan Curtis
• Visual Crit Fun Time,Tom Harman
• Brain Tree Critiques with Figma, Carmel DeAmicis