Mitigating risk before an MVP launch

Summary

A PM manager from another space in the organization reached out to me after seeing a presentation I gave on Object-Oriented Design and how I used it in the Promotions' domain. She was curious to learn how this approach might help her team rethink how they were going about designing an Order Management MVP.

Learning about team dynamics & organizational pressure

Going in blind as a consultant of sort with this Order Management team meant I needed to address a few things upfront.

‍

How would they perceive me from the get-go & moving forward? Could I find ways to build trust and rapport with them quickly? What could I learn about this team before we start the work & as we make progress together?

‍

To answer some of these questions early on: I met with the Lead PM, Engineering Manager, and Product Designer individually to understand their takes on their team and any potential pressures they might be under.

‍

I observed that:

• The Order Management team was very young (~1.5 years old)
• Several members had been recently removed from the team and replaced with others after a large re-org within the company
• Engineering leadership had the most subject matter expertise & historical knowledge, but they were also viewed as the hardest to work with
• PM leadership wanted this team's MVP to include an AI chatbot, and the members were planning on obeying that desire
• Designs for this MVP were already "done" by a Designer who recently left the company, but they were not implemented due to the AI push
• The 3 people I spoke with believed these designs weren't tested with users and that the requirements likely came from the product team's assumptions

‍

When I considered this new information, it affirmed that Object-Oriented Design would be an appropriate methodology in this situation. [Happy to go more into why I believed this was right over a call]

‍

If it wasn't the right approach, I'd work with the PM Manager to recommend other options to lead the team through.

A little bit of teaching...

Disclaimer: I'm not going to spend much time covering the ends-and-outs of OOUX or OOD in this case study, because there are many resources out in the ether already. Instead I am focusing on its application, the effects it had on the team, the choices we made together, and the iterative artifacts that were created for testing purposes.

‍

Before we met, this team had never heard of Object-Oriented Design, or more commonly referred to as Object-Oriented User Experience (OOUX). Sophia Prater pioneered this methodology and made it accessible to a wider audience - with its earliest roots coming from object-oriented programming.

‍

I knew I had to educate the team on this methodology, but I wanted to be mindful of their timeframe so they received a brief crash course before we put it into practice. And because I am goofy dude, I couldn't help but infuse some poor humor into getting them up to speed.

‍

... a lot of practice

‍

Session 1

After introducing the team to Object-Oriented Design in the first 10 minutes of the initial, hour-long workshop: they began identifying the objects in the known Order Management ecosystem. It's honestly difficult to start the ORCA (Objects, Relationships, Call-to-actions, & Attributes) process, because you need to begin with the objects that users interact with, and our brains tend to struggle to grasp them in a very digital world.

‍

But this small team (including PM, PD, TL, Data SME, & Eng. Mgr.) kept pressing in to discuss & critique each proposed object to then begin prioritizing what objects were most important & feasible to include within the MVP scope.

‍

The "Objects" portion ran a bit smoother than previous ORCA sprints I've facilitated, because I did a bit of digging in the team's product repository to find some past epics, personas, domain vision, etc to pull out a few potential objects for the group to react to rather than starting from a blank slate.

‍

At this point, we were calling to mind the valuable, real-world things that exist within this problem domain.

As expected though, the team experienced a few disagreements & points of confusion based on doing this activity:

• People wrote things like "API Service," "Dependency," "App," etc. as objects early on, because they were listing out the necessary things to be aware of as they build the MVP (which they certainly are!). However, they removed them once I gently asked them if they were objects the users were aware of or were needed to accomplish their main business processes. The exception is "App." It is technically an object but a terrible one at that, because it is far too broad & ambiguous to make considerable sense of.
• "Ticket," "Incident," "Problem," & "Issue" were all objects used interchangeably amongst the team members. My advice to them in the short-term was to agree on one object that best represented all of the noted objects to carry through our ORCA sessions. Once we were done though, they should go to a handful of users to verify whether the object they named reflects what the user community calls it, and if it doesn't, then they need to align it to the users.
• "Order Type," "Status," "Fulfillment Method," etc. are all attributes and not objects. We moved them off to the side, because we would eventually identify all of the attributes per prioritized object in a later session. In the meantime, it was easy to say "Order Type" is an attribute of an Order object.

‍

Once the team had a prioritized list of objects, they defined each object and made sure everyone agreed with the definitions to avoid the likelihood of more misaligned assumptions cropping up in the future.

‍

This was just one of many points of clarity in the process that the team could start from the same level of understanding.

‍

Session 2

After the O step of ORCA, the group focused on understanding the RELATIONSHIPS between objects.

Using a Nested Object Matrix, we put the objects in context to one another by addressing their cardinality (e.g., an eComm Order can have 1 - many Events), and described the implications of those relationships - like a child-parent association.

‍

This R step helped illuminate the navigation and layout needs anticipated for the Order Management MVP, and it also empowered the team to think about how they might design the authoring experience.

‍

When we laid out the relationships in this way, we also uncovered hidden object dependencies.

There was plenty of healthy debate between Product, Design, and Engineering at this point, because the chosen objects started to make even more sense to them as they subjectively decided whether they relate to others and what those relationships looked like if so.

‍

Session 3

From R to step C, the team diverged on all possible actions users could take on the prioritized list of objects.

The 3 main user groups or archetypes that were chosen were the Strategists (e.g. eComm Strategy Managers), the Doers or Operations (e.g. Regional Transportation Managers), and Technology Partners (e.g. this product team and also support roles).

‍

It's intentional that we captured the actions at this point in the process, because the team had built a solid understanding of the system & its objects before figuring out who does what and with what object.

‍

The Lead PM even surfaced future actions that users might take as the product evolves to meet their needs.

I encouraged the group to also ask themselves the following questions to further clarify hidden product requirements:

• Why did [X role] take that specific action?
• When does [A action] happen in the flow? What triggers it?

‍

Even with me knowing so little about this space, I was able to quickly point out who the primary users of this Order Management application would be, because they are ones who are able to perform the most actions on the objects (outside of the admin-type roles).

‍

At this point in the ORCA process, the team could begin to write a comprehensive list of use cases to influence what would go into the product now vs. a later date.

‍

Last session

Last but not least, we landed on step A of ORCA. The attributes! The stuff that makes up the objects.

‍

I chose to extend how long this session would take purely based on this product not being customer-facing. Since this product is for the enterprise, the internal users and the data required will need further clarification.

‍

For each of the 8 objects, the group identified all the core content and metadata they were comprised of. I then showed them what it would mean to better define each attribute for the purpose of mitigating any misalignments between the product trio.

For each attribute, the team should know:

• Is it required? [write Y or N]
• What type of data is it? [i.e. is it a number, string, boolean, array, date, ...?]
• How is it formatted? [e.g. "19 digits; cannot be null"]
• Where does the data come from? [i.e. what is the source system, if not user-generated?]
• What might change its state? [i.e. what attribute/object, if any, can change the state of this attribute?]
• Who cares about it? [i.e. the roles that have access to it vs. all roles]

Putting it altogether

If you noticed, we were creating documentation each time the team met. So they didn't need to spend any time between sessions summarizing what we accomplished, because it was there as clear as day in the virtual whiteboard.

During that time however, I was inspired by another Designer in a completely different industry who created a visual version of an object model that I took a whack at doing something similar with and would give to the Order Management team.

‍

Each "Object Card" contained the:

• Object Name
• Object Definition
• Object's Attributes
• Actions
• Object Relationships

Holding them altogether like they are Pokémon or baseball cards, the wielder has a working system ready to go. Any layman could look at a card and walk away with a good enough understanding of what it is, how it relates to other cards, and what actions could be performed against it.

‍

The value for the team comes through testing these cards with the business and its users to discern how accurate they are and to show gaps when they are not. In other words, they don't have to begin their MVP exploration by creating wireframes!

‍

I continued to suggest to the team that they keep questioning their assumptions and build it as a practice within their domain.

As an example, they could take the Location card and ask business leadership & users:

• Have we defined "Location" accurately?
• Are we missing any attributes?
• How else do you interact with the "Location?"
• Why is the "Timezone" attribute important to you?
• Should the "Location" always reference the "eComm Order?"
• ... plus much more!

‍

Object-Oriented Design puts everyone on an equal playing field, focusing the conversation around the objects and not the actions first, and removes the ego from the room by looking at the whole environment agnostic of the current systems at play.