DEV Community: Quantum Mob

Get Ahead by Going Headless

Quantum Mob — Tue, 09 Nov 2021 18:43:19 +0000

A familiar architecture

Over the years, ecommerce has developed an online infrastructure that's in many ways similar to how businesses have operated for centuries: a comprehensive and deeply interconnected set of essential components.

In ecommerce that means the database at the heart of the company has a data access layer and a layer dedicated to business logic forming the backend. These connect to the user interface the client interacts with, the frontend. Just as a successful brick and mortar business might carefully integrate its retail, sales, and fulfillment aspects, ecommerce has evolved to group all its components into a single "monolithic" platform.

These centralized and feature-rich monoliths powered the early and middle generations of online retail and services. However, as the businesses using them became more complex and needed to scale or adapt more quickly to competition and innovation, it became clear that this approach had serious shortcomings as well.

The systems are highly interdependent, creating bottlenecks such as one system being held back by slow development of another, or a failure of one system cascading across the platform, where a single bug takes down the whole operation. Not to mention the complexity of the codebase, which slows down innovation.

From mono to micro

The new online economy has fostered countless new companies that have hyper-specialized in pieces of the ecommerce machinery. From payment processors and inventory management to recommendation engines and loyalty tracking, this new crop of "microservices" made adding features like "buy 3, get your 4th free" deals as easy as an API call.

Soon, however, it began to be possible to basically assemble the equivalent of a monolithic platform simply by plugging microservices into one another. This "headless" architecture has lots of benefits beyond mitigating the risks of being responsible for every piece of your ecommerce business in an increasingly complex, competitive and fast-moving environment.

The decentralized nature of a headless system means that scaling and development of services can be done independently. Each microservice can be upgraded on its own if necessary, for instance, if there's a sudden interest in a new commerce trend, you have the ability to integrate the new service into your platform with the least amount of service disruption. Omnichannel sales experiences can be established on the frontend that connects seamlessly with the same backend, reducing friction for experiments with new brands, features, and devices.

The corollary to this is of course that you only use what you need, so no resources are going towards running a service that's not being used. Microservices, like computing or web storage, can be maximized or minimized on demand.

It's much easier to add and integrate new services and adjust code bases as well, since microservices are independently maintained and interact with each other using secure APIs and other backend channels. No need to hire up to add fraud protection or customer support chat — they can be added, tested, and evaluated for further development with far less risk and resources.

Lastly, it's a benefit for security and liability purposes. Siloing customer and business data among several secure systems make the likelihood of a catastrophic database problem practically nil. In the worst-case scenario, if something is compromised, the data and access to a service exposed are minimal.

Putting headless to work

We recently helped a client turn around a totally new loyalty program in a matter of months. The only way such a thing is possible is because of the availability and flexibility of microservices; this way the marketing, UX, and development teams could work hand-in-hand knowing the exact impact, output, and specifications of each part of the system.

Moving to a new framework, optimizing for mobile, building out a CMS ready for high-traffic volumes, and of course, doing this all with bilingual support baked in at every step — all this took place in a handful of months and led to a 30 percent increase in loyalty point redemptions as well as a more satisfying user experience.

Whether you're launching something new or looking to revisit your own monolithic setup, Quantum Mob can help you find the partners, services, and expertise you need.

Omni-Channel Loyalty Programs: A Strategic Imperative for Seamless CX

Quantum Mob — Thu, 07 Oct 2021 20:46:20 +0000

The Traditional Approach

Traditional loyalty programs prefer to reward spending rather than for engagement. They are uni-channel and card-based in which customers receive tangible benefits, such as a discount or a free product. With this approach, traditional loyalty programs appear as cheap currency to the customer. These benefits are only available to return customers who entered the store and made a purchase. They rarely reward behaviours that lead them to the store. Once customers have their wallets full of different loyalty cards, the loyalty effect nullifies.

The Omni-Channel Approach

Omni-channel loyalty combines technology and innovative customer experiences to deliver relevant offers at the right time, bringing customers back to the brand regardless of where, when, or how they shop.

“A good customer experience can be defined as seamless and a rewarding interaction with a brand at every touchpoint. It goes beyond one-dimensional discounts and instead offers deeply personal and authentic customer experiences that yield stronger engagement and higher spend among customers,” says the technology mega-corp Oracle in their research focussing on Omni-channel Loyalty.

Omni-channel loyalty maximizes cross-channel loyalty through real-time campaigns. It integrates all customer transactions and engagements into a singular, unified brand experience. Redesigning the entirety of an experience rather than only maximizing their point value is the key to create a truly seamless customer experience with brand loyalty at the core.

"According to McKinsey, 75% of shoppers tried a new retailer, brand, or behavior during the pandemic with up to 83% expecting to continue those new traits post-pandemic. This means loyalty is up for grabs and retention now becomes mission critical."

How to design an Omni-channel Loyalty strategy?

Be Where Your Customers Are

When your loyal customers are looking for your product or service, you should know where they are most likely to begin their search. Customers expect to be addressed on their platform of choice. Remember they may not have the other channels set up or know how to use them, so it is always a good idea to engage them where they are. Digitize your loyalty program so you can extend promotions across websites, mobile, and social media, allowing customers to transact and interact with your brand. Customers expect to contact your company in whatever way is most convenient to them.

Find out how Canada’s most recognized loyalty program increased member reward redemptions by 30% by launching a modernized website and focusing on user experience.

Personalize interactions using Data

Insights from a Gartner survey show that brands risk losing 38% of customers because of poor marketing personalization efforts. Use the customer data collected across all channels to identify trends, behaviours, preferences, and segments to personalize communications, experiences, and promotions for your loyal customers. Rewarding prospects with incentives for their information, such as first name, birthday, preferred communication channel, phone number, and list of products they’re interested in is a good approach to collect relevant data on new prospects.

Check out how a perks-based loyalty program revamped its digital platforms to handle a larger volume of users, optimize their experience resulting in 2x request speed, and 6 seconds startup reduction.

Reward Social Engagement

With a large number of social media users, earning reward points for social engagement will give customers the impression that reaching a certain number of rewards points is achievable. These attainable milestones will increase their likelihood of participating in your program.

Connect with and reward customers for social interactions. Expand loyalty beyond transactions and focus on an expansive emotional engagement. Engage social influencers as your brand ambassadors to further your reach and engagement.

A Strategic Imperative

Developing an omni-channel loyalty program is not an option, but a strategic imperative. As many brands adapt to the omni-channel way, traditional loyalty programs need to evolve to meet ever-rising customer expectations. Successful omni-channel loyalty programs find opportunities to reward customers at multiple touchpoints across every channel through seamless integration. They deliver convenience, relevance, and value for customers across all channels. An omni-channel strategy helps retailers collate data and form a holistic view of their loyal customers, enabling them to build meaningful relationships, improve engagement, and enhance satisfaction.

If you have any questions after reading this article or you are curious to understand how to build these digital loyalty experiences that deliver results for your brand or loyalty program, feel free to reach out to me at hello@qmo.io

Here’s Why Your Team Needs a Product Manager

Quantum Mob — Wed, 09 Dec 2020 21:35:10 +0000

What does a Product Manager actually do? If you were to ask 10 Product Managers to define their job, you’d likely receive 10 different answers. Why is it so difficult to define a Product Manager’s responsibilities?

In 2012, Ben Horowitz, CEO of Opsware and Co-Founder of Andreessen Horowitz, defined the Product Manager as the “CEO of the product”, which has been the standard for many years.

This definition, while concise, does a good job at highlighting the wide breadth of responsibilities of a Product Manager, including everything from “Motivating the team”, to “Defining the Problem/Product”, to identifying “What success for the product looks like”. While defining the role in this way can help establish a high-level understanding of the role, it only scratches the surface of Product Management.

What's the need?

Team culture and makeup are significant contributing factors to the complexity of the Product Manager’s role. This varies from team to team and depends on a variety of factors, including the complexity of the product, the size of the product team, and the team’s expertise. For example, on a small product team, the Product Manager will, out of necessity, need to wear multiple hats to help the team operate effectively. As the organization grows however, and hires contributors in more specialized roles, the Product Manager’s priorities shift to more effectively navigate the team towards the desired outcomes. They leverage their negotiation and motivation skills to drive the team, balance business and customer needs, and achieve an outcome to build a great product.

Product Manager vs. Product Owner

Finally, the difficulties of overlapping roles and responsibilities. There has been a long lasting debate on the difference in responsibilities between a Product Manager and a Product Owner. In general, the Product Manager is the one that usually defines the product mission and vision, identifies high level problems or risks, and defines what success looks like. The Product Owner’s responsibilities are taking those high-level problems and breaking them down to day-to-day activities for the team to run with, whether it be breaking down a single requirement and drafting appropriate stories, or managing the day-to-day backlog.

What we are seeing in industry today is that Product Owner is less of a role, but more of a responsibility. Product Managers that do exceptional in scaling and managing the team, can empower the team members to wear the Product Owner hat. As an example, if you are managing a team with multiple components, you can get team members to take responsibility for each component. That way, the Product Manager is empowering the team members to take ownership of the work and represent themselves as leaders.

In 2011, Martin Eriksson, founder of ProductTank, introduced this Venn diagram. It was the catalyst to heavy debate and significantly misunderstood.

Martin defines Product Management as the intersection of User Experience, Business, and Technology. A lot of people have misinterpreted this as a Project Management function. Basically as a person who sits in the middle and facilitates all 3 departments. But in reality, Martin was trying to highlight one of the most difficult responsibilities of a Product Manager, making great tradeoff decisions. In other words, championing user experiences that are technologically feasible, addressing a business need, all while solving a great customer problem.

To recap, a Product Manager is responsible for the product and its success. They carry out this responsibility by taking a CEO-like responsibility for the product, but without leveraging the authority a CEO might possess. Another key characteristic of a good Product Manager is that they empower the team members to take individual ownership over the product or its components, while the Product Manager can focus on effectively balancing the needs of Engineering, User Experience, and the Business.

Now that we know what a Product Manager adds to a product team, does your project need a Product Manager?

The Product mindset

The main point is the Product mindset. A product, in this sense, is a digital service be it a new platform or a new app, that enables a user to complete some sort of activity. A project is a set of steps necessary to bring the product to a specific outcome. Traditionally, Product Managers have been more project-focused, defining an end deliverable and setting scope at the start of a project then mapping out how to get there. Being more product-focused means looking longer-term at the product and its intended outcomes. It allows the product strategy to flex over time and respond to its ever-changing environment.

Your Product Manager will:

Understand why this solution is being developed and exactly what features will be developed
Apply a value lens, identify both user and business needs to pinpoint key value drivers
Own and communicate the strategic direction, documenting through a product roadmap
Engage stakeholders for buy-in
Focus on customer insights and adapt priorities as necessary
Prioritize features and new ideas based on a measurement framework
Lead the team to overcome obstacles
Provide input on the products’ business case for expected costs and benefits
Use analytical and creative problem-solving skills to deliver valuable outputs
Communicate the progress to stakeholders

Key Takeaway

Creating a product and taking it to the market is not an easy process. It can involve numerous stakeholders and decision-makers, and countless hours of effort and dedication. Equipping your team with a Product Manager will ensure that the efforts of your team and hours put into imagining, planning, and developing the product will yield a strong business return, and cohesive Customer Experience.

How to Use Acceptance Criteria to Ensure Software Delivery

Quantum Mob — Tue, 17 Nov 2020 21:28:38 +0000

Acceptance Criteria and User Stories are some of the terms we hear day-to-day in an Agile Software Engineering environment. Working with multiple client teams over the years at Quantum Mob, we've noticed that not everyone uses them, and those that do typically misuse them. They can be directly responsible for making a software engineer's life a confusing nightmare without having a clear indication on what is expected for deliverables.

What do these terms mean and how can we use them to ensure software projects get delivered to everyone's expectations? In this article, we will deep dive into the Acceptance Criteria and User Stories in software development with examples and demonstrate how they can be used to create accountability and ensure a project's delivery.

Definitions

User Stories

User Stories are generalized details of the system's user requirements and what the client hopes to gain from this functionality. In Scrum we have User Acceptance Criteria to simplify the understanding of the client’s intent or translate the intent to an actionable item.

Acceptance Criteria

Acceptance Criteria are a formal list that fully enumerates user requirements and all the product scenarios put into the account. It states the intent of the client and not the solution; it is up to the team to understand them and ask for clarification where it’s complex and find the solution.

Acceptance Criteria in Software Development

A software development project is typically divided into a set of tasks, and after each task is completed, it is confirmed whether they meet the requirement of the project development scope. This is made possible by the use of the Acceptance Criteria.

Before the actual coding of any project can begin, planning and estimation of resources and timeline information are required. The use of Acceptance Criteria allows for the easy division of tasks, which can then be easily budgeted and assigned.

Feature development with User Stories and Acceptance Criteria
Flowchart of Acceptance Criteria

How to write Acceptance Criteria

Acceptance Criteria should describe achievable and sensible information. It should provide the minimum level of functionality the product is to achieve, allowing space for some flexibility. Also, it should not be overestimated or underrated, but set at a realistic level.

Great criteria are well detailed and defined so that the team members can easily comprehend what is required of them and easily employ the information in development. Just as the project is divided into tasks with the help of Acceptance Criteria, the criteria should also have a reference checklist to see whether the User Story is covered.

Using Acceptance Criteria to ensure development standards
Acceptance Criteria doesn’t need to be strictly used for describing the intention of the client. As a development team lead, you might want to ensure certain standards. If you’re adding new components to a component library like Storybook, you might want to add certain knobs and settings to be implemented as acceptance criteria. If you wish to ensure unit testing, you may list a specific unit test as a part of the acceptance criteria.

How do I know if I have written good acceptance criteria?
A good Acceptance Criteria is readable and understood by all stakeholders who are concerned with the User Story. In order to ensure clear Acceptance Criteria that all stakeholders can derive value from, avoid the use of jargons.

Formats with Examples

We recommend following the formats below to create clear definitions your team can act on.

User Story:

Let's use the following User Story to consider what the Acceptance Criteria may be.

Displays text: As a (user) I can (function) so that (rationale/achieve some result)
As a Registered ABC Company user
I can see the membership expiry date
so that I know when I have to manually renew or enable auto-renew.

Acceptance Criteria (not formatted):

The membership expiry date is calculated.
The membership expiry date is displayed.
The manual renew option is displayed.
Option to opt-in to auto-renew is displayed.
Membership details are not displayed if the user is not registered/authenticated.

Acceptance Criteria (formatted)

Displays Acceptance criteria format: Scenario - This is the title of the condition to be acted upon. Given - an initial condition. When - something happens. Then - this is the result.

Scenario — Displaying options to renew ABC Company membership on Billing Details page
Given — A valid user is logged in
When — Has a valid ABC Company membership with an expiration date
Then — Show the option to renew membership manually or opt-in to auto-renew

Wrap-up

In summary, Acceptance Criteria describes the intent of the client, i.e. his/her idea of what the User Story should be like. It is up to the team to develop the solution to the User Story.

Writing a good User Story and an Acceptance Criteria is difficult but a really important task in Software Development that determines whether the software does what the user is expecting or not and finally measures the quality of the product.