Marketplace Models Definition

The problem

One of my first projects at Varis was to help others in the company understand different marketplace models that exist in the B2B procurement space (and ultimately those that we hoped to service) to facilitate discussions at all levels of the organization - from explaining concepts and complexity to C-level stakeholders, to understanding the many different humans and roles that exist within the B2B procurement space, to new product and feature prioritization. The individuals hired to solve the problems in this space had a hard time distilling over 15 years of knowledge into a format that could be used and easily understood by those at all levels of the organization, so really my job was to get years of expertise out of 3 very smart brains and on to paper.

The approach

I scheduled a virtual brainstorm with the Head of UX, Principal Technology Lead, and Principal Technical Program Manager. Using LucidChart, I began outlining the marketplace models real-time as they discussed it, allowing them to work through what was in their heads.

After many iterations and additions, I ended up at what you see to the right. The diagram not only explains the types of procurement marketplace models that Varis hoped to service, but connected to the types of business models and the customer roles that exist within those businesses. Those customer roles were expanded upon in the form of persona-like customer problem cards that were used for every project going forward.

The outcome

Originally rolled out in 2022, this diagram was used until Varis’s dissolution in 2025 by all levels of the organization to explain new business opportunities, customer interactions, in sales discussions, and to customers themselves. It was a foundation for understanding and alignment for the organization.

Back to top

Product & Technology Collaboration Points Map

The problem

In growing, remote organizations getting teams to collaborate is one of the hardest problems to solve. Varis’s growth was unlike any organization I had ever been in. In a little over a year, we went from about 20 employees to over 300! Sure, we had Confluence and Jira, but with growth comes disorganization, making those tools near impossible to navigate.

Additionally, the very technology-focused teams had very little understanding of how the features they were being told to build related to each other or the overall customer journey to create a cohesive product.

The approach

As a Foundational Designer and Principal UX Strategist, I had the unique position of working with pretty much every team within the organization and took an initial stab at diagramming how the teams at the time fit into the primary customer’s journey, what features existed in that part of the journey, and where critical collaboration opportunities would arise as teams try to meet their goals.

Varis’ first big initiative was creating a marketplace built on Microsoft’s Business Central product for small businesses to procure items sourced by Varis on the Business Central platform. I had just finished outlining the customer journeys for this product, so I started there and then outlined the features that existed within each part of the journey. Each feature consisted of backend services that were being worked on by one or multiple teams.

The hard part came when trying to discern which teams were working on what features. Because of all of the growth, teams were constantly changing but luckily those services and the leadership working on them were pretty stable, so I listed the Product Manager, UX Designer, TPM, and Development Leads assigned.

The outcome

After distributing this map, there was a visible increase in teams identifying collaboration points and including members of those teams in critical discussions earlier in the product development lifecycle and the customer journey was referenced more in technology-focused discussions. There was also a In doing this exercise, I was also able to quickly identify prioritized features and services that weren’t staffed, which led to staffing, prioritization, and budget discussions with leadership.

Overall, this document became outdated pretty quickly as growth continued, but it served it’s purpose at that time to lay foundations of understanding that then got integrated into every discussion we had as an organization. Confluence and Jira templates were updated to include customer journey phases and collaboration points at the beginning of the project which perpetuated this work in a more easily updatable way.

Back to top

Varis Platform Evolution

The problem

Varis was built on an acquired PHP based product called Buyerquest that had an entire team - developers, product managers, a sales team - supporting a large number of customers who used it daily. There was some goodness under the hood that we wanted to keep and modernize and the existing product team still had a backlog of features that were actively being built on the old platform. Unfortunately, there was no way we could simply deprecate or stop building on that platform while we were building the new evolution.

At the same time, we had a new sales team that was excited to get customers on the new platform but didn’t want to overpromise features and functionality to prospective customers and due to the complexity of procurement, individual contributors who has no idea what they were building toward or how to get there, and an organization that didn’t have a good picture of how leadership expected to make a product vision actually come to fruition.

The approach

After putting a draft together, I showed it to product leadership to gain their unique perspectives that would apply to each audience:

• The UX team wanted to understand which customers and journeys would be incorporated into each iteration and how to make the old and new systems seem seamless to customers.

• The Technology teams wanted to understand the backend languages that would be used, which services and features would need to be included when, and how new and old technologies would need to talk to each other but still be built separately to allow for decoupling later.

• The Product and TPM team needed to understand how to enable all of what the UX and Tech teams were building, while also thinking about future features that customers were asking for.

• The Sales team wanted to understand what features were planned when, so they could sell to the appropriate customer base and more efficiently communicate how we planned to meet their needs over time.

• The Customer Support team wanted to understand where the product was at any given time to be able to help customers with existing problems and as new features were turned on.

• C-level leadership wanted to be able to communicate to stakeholders and investors a long term vision for the organization and product.

The outcome

This product evolution map was wildly successful in helping all audiences in the organization get on the same page about our product’s evolution. It was referenced in meetings at all levels of the organization to garner understanding and prioritization of features and functionality and became a tool that the sales team actively showed potential clients.

Back to top