The aim of this post is to give you a view into how onboarding works at Moltin. It is designed around a service based implementation.
Our onboarding structure consists of a number of sessions together, followed by a regular cadence of standups. The upfront sessions are designed to compile a clear picture of the project, and they tend to look something like this:
In all of these sessions, there are going to be unknowns, and that’s ok. For example, you may not know which OMS you plan on using, or what the fulfilment workflow looks like. Through the process of doing these sessions the unknowns will become explicit, and that’s part of the purpose!
In a services based implementation, there will likely be many other best in class services operating alongside Moltin. These could be transactional i.e. email, sms, push or more internal i.e. a CMS, OMS and so on. It is important that these services be identified and added to an architecture diagram. The diagram should contain the services used, but also the technology stack including the development language and hosting. This session therefore normally takes place as a brainstorm. Here is an architecture template example we use to get started.
Now that an architecture diagram exists, together we begin to look at what the arrows between services mean. A lot of nuance can hide in these arrows, so making the flow of data between services explicit as early as possible has numerous advantages for design and build. Generally there are two kinds of data flow, a customer interaction, and an admin interaction. These can be modeled as user stories in order to keep the exercise grounded:
- As a user, I am browsing the website intending to buy X for Y
- As an admin, I am creating a new promotional campaign for the company
Together we go through each story, and identify what flow of data must happen in order to fulfill the needs of the story.
This session could be seen as the kickoff. It normally involves a large set of stakeholders. Once you have an architecture map, and data flows documented, it’s generally a good time to begin planning out the actual build together. We have a template for this here, and will walk you through it.
Before getting to sequencing of work, we generally try to clarify the primary and secondary objectives of the project, and always use these as a point of reference. The primary objective is the reason the implementation is planned in the first instance. It normally references a financial objective and it should be easily measurable. You should know by checking this objectives measurement whether the implementation is a success or not.
The secondary objectives flow from the primary. They are the major milestones which must happen in order to reach the primary. For example, if the primary objective is to increase revenue by 10% in the next 12 months. The secondary objectives might be:
- To open a new D2C online ecommerce channel through a spin of transactional website, offering a subset of products purchasable directly.
- To make this channel available and functional within the next three months.
Once the objectives have been defined, we also look to understand the stakeholders involved in the project and their roles/needs. This allows everyone to see what groups should be present at what stages, and how the feedback loops can be defined in order to prevent requirements changing too much later and thus introducing scope creep.
Then, it’s on to activity sequencing! Due to the nature of an ecommerce implementation, this can get tricky - especially while operating an agile process.
Increments of UX get generated piecemeal, front end and back end sprints need to be kept synchronized, and different stakeholder needs have to be emphasized at different times throughout the cycles. You are never going to have all the requirements upfront, and these requirements will undoubtedly change while the build is in progress.
Therefore we have found that short increments of work with frequent sprint reviews work best to maintain momentum whilst maximizing adaptability to new or changing information i.e. your feedback loops. We define a week by week schedule of outcomes, extending out until the projected launch date. These outcomes intertwine UI/backend/design/product/marketing and so on. For example, the outcome for week 3 could be to have a mockup of the cart page complete and a functional prototype of the customer account page demo-able.
Now it gets easier to design a resource and requirements plan, based on this sequencing of outcomes. Generally it results in a conversation like this:
“Hey I’m going to need to have the requirements spec ready to start design of the PDP by this time in order to reach that outcome.”
“Oh, that’s going to mean the product configuration we offer must be clearly defined before then because otherwise I can’t provide accurate specs, I’d better speak with the product team about this during week X”
As these conversations play out, the flow of information generally becomes explicit, allowing us to then schedule some meetings/further sessions with subsets of stakeholders. Using the above example, a meeting could be scheduled between your product team and Moltin to model the product and the configurability offered to the end user.
At this stage you normally end up with a set of sessions to be scheduled immediately, and it’s a good time to lay down the way in which you work together. Most of our customers are happy with a weekly sprint review together, with ad hoc sessions based on the outcomes needed for the coming weeks.
At this stage you’re ready to rock and roll with the project! It’s time to make sure your teams are in tune with Moltin and the support available to them. This becomes more important as you move towards a production launch and we find it best to get familiar with support as early as possible. We have a general support presentation to help you learn about support channels.
On training, all of our documentation and materials are open source and available via https://www.moltin.com/developer. You can start by making your first API request, and take a look at our reference architectures.