How to balance product growth and stability

There is always the risk of unplanned changes in priorities within any payments product, regardless of its life stage. When priorities change, velocity estimated to deploy revenue-generating features can vary from month to month. Customers can then become dissatisfied, especially those that have been promised specific timeframes for delivery of certain functionality. Product and development teams can both suffer lower morale due to potentially higher stress and distraction. It’s a downward spiral that can often be prevented.

So how can a Payments Product Manager / PM prioritise effectively, should demand seem to change all the time? Here are some lessons I’ve learned to use to help safeguard yourselves from complete meltdown:

1. Communicate your product vision. Over and over and over again.

“Be stubborn on vision but flexible on details.” — Jeff Bezos

In our last post, I spoke about the need to communicate well with the CEO and to over-communicate with everyone else. Over-communication is extremely important for the Product Vision: the why a Product is being created and what it aims to achieve for its users. It sounds obvious, but if your team doesn’t know what the end game looks like, there’s a high risk that there is no viable path between MVP and sustainable growth.

A distinct vision also signals certainty and confidence and motivates technical teams to work towards a common goal. This is quite important in an industry like the payments industry because there’s always the tendency to slightly widen the scope to try to address a trend or customer need that is somewhat outside of the area of sheer focus. Communication can be in the form of artefacts (e.g., vision boards), frequent presentations, brown bags, you name it.

Take, for example, Littlepay: as a transit payments processor focussed on contactless EMV (Visa / MasterCard / etc) payments, it could theoretically reapply its low-value / micropayment solution to other payment media and segments outside of transit. It doesn’t rule out the possibility of growing into these new areas, but our current focus on transit contactless payments has helped us focus in on solving the biggest pain point in transit payments today: offering an open-loop (bank card) alternative to cash. [For more information on our Product and business, simply visit Littlepay.com]

In an early-stage company or startup, or at the beginning of product discovery or prototyping, it is OK to change the vision if you need to iterate it based on a major customer finding or insight, or perhaps even a change in compliance, as long as you communicate the reasons, data or logic for the change. Communicating reason and intent for the better of the company is largely more important than not changing the vision in the fear that it may disrupt existing business.

2. Understand the different types of product development

Having worked with and within Product functions in payments businesses, I’ve seen broadly 6 types of product development work in common across each company. While I’m open to hearing more, I think below are “MECE” enough for the purposes of a medium article of brevity :)

A) Revenue generating feature increments

these are your standard value creation increments. Pieces of functionality that address a customer pain point or requirement that have some impact on revenue growth.

For example, a new feature that allows more payment channels into the system (e.g., an API), a front-end of configuring transaction processing rules, or perhaps the underlying fraud detection engine that reduces fraud while also allowing for premium pricing to be charged.

B) Integrations

Integrations are investments in growth through either new channels into the payments platform, or to new payment networks that allow for geographic or market expansion. While integrations do not enhance product functionality, it widens the pipe for more transaction growth to occur and are typically more Epic in size (rather than just user story level) especially in a market landscape where suppliers have older legacy systems that have not usually exposed themselves to web services. For example, an integration could be connecting to an alternative payment network to support a specific payment method, or potentially a new merchant acquirer that operates outside of current reach.

C) Operational maintenance

These are non-functional features (security, reliability, availability, all the ‘-ilities’ you can think of) that enable the payments products and services to be delivered to the customer. Think of these as tasks that ‘keep the lights on’ and measure low on customer satisfaction but high on usefulness and need. Expect a fair chunk of this work, given that there is the standard expectation for payments systems just to work, be highly secure and available at all times. These work items differ to compliance because they may be unrelated. For example, a feature that monitors availability levels across devices or systems to adhere to a contractual Service Level Agreement.

D) Compliance

these are system enhancements or increments that address adherence to compliance requirements, such as security requirements (e.g., Payment Card Industry Data Security / PCI-DSS standards) or those mandated by a payments network or scheme such as Visa and MasterCard for each step of the payments value chain (e.g., card to terminal, terminal to PSP, PSP to the acquirer, acquirer to scheme, the scheme to issuer). Unfortunately, these requirements can often significantly disrupt your backlog, but there are ways to mitigate this risk through culture, structure and mindset — mentioned later in this post.

E) Technical debt

Also known as design debt or code debt, this is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Technical debt can often be translated to monetary debt, especially if a decision to delay a better plan prevents certain revenue-generating functionality from being released. Technical debt sometimes could be wrapped up us a lower-level task that underpins a revenue-generating feature or compliance user story.

Knowledge building

Tese features improve the overall capability of your development team’s understanding of both the limitations of the Product and may create new revenue streams. Still, such revenue isn’t guaranteed because the innovation isn’t tried and tested in the market. These items invite engineers to be creative, improves motivation, and in turn, can bolster staff retention. This mimics experiments that Google engineer’s design during their “20% time” (for more on this, see “Work Rules!” by Laszlo Bock), but in reality, your product backlog may be so full of exciting work that existing challenges already engage your engineers. Regardless, what’s important is the culture for innovation and knowledge building ideas to be allowed.

So, which of the above types of product development should your Product be focussing on today? Well, the answer, of course, depends on your product culture, product workflow and prioritisation methods, and stage of your Product’s overall lifecycle.

3. Inculcate principles of Agile; don’t just implement specific templates or frameworks

It is far more essential to remember the overall tenets of Agile than to implement particular frameworks, such as the likes of Scrum, Scrum Planning Poker, Scrum at Scale, SAFe, etc. If you need to, simply take the best bits of the frameworks you feel would benefit your teammates, and test them out. If they don’t work, drop them. If they do work, keep them and see how it fits in with the rest of your company.

While I can’t disclose fully the specifics of the work we did at Littlepay from inception to today, I can give you a bit of a snapshot of how the type of work effort changed over time. Below is a sample snapshot of increments by work type, by time.

As you can see, there were distinct periods where development focused on implementing ‘must-have’ functionality to adhere to compliance requirements (e.g., PCI-DSS). At other times, operational maintenance issues were being addressed due to bug fixes and stabilisation of our platform is being worked on for future growth. Integrations then grew and shrank rapidly depending on various factors, but mostly due to strategic partnership opportunities and market expansion. At any point in time, shifts in work type changed on a monthly basis.

The question still remains: is changing the focus of our resources towards different work types on a frequent basis a bad thing? How do we limit the amount of disruption to the product plan? Well, there are a few things you can do. You could also set % utilisation targets per work type, differing by time period. For instance, you may want to set a goal of 70% for “Integrations” within a single calendar quarter (3 months), where the entire business works on expansion initiatives while the product functionality remains relatively static and stable.

⚠️ Warning: if you use such limits, you must be ready to say ‘no’ to anything that may carry work over this 70% threshold. Think of it as a significant budget that needs to be adhered to with severe implications on employee satisfaction and morale. Hopefully, you have a culture where if Product says ‘no’, people agree (or perhaps disagree, but still commit to working towards the decision).

Ultimately, the most important thing to do is to create some sort of Agile product release workflow that follows your organisational culture, a product roadmap (sequence of activities) and an overall prioritisation framework to justify decision making.

4. Use a pull-based work system where changing priorities are welcome

The Agile manifesto places greater importance to “responding to change” rather than “following a plan”. Don’t get me wrong, plans are great. Still, in today’s changing competitive landscape, change is frequent and expected. In payments, user purchase experiences and payment methods of choice change all the time, whether it be due to new regulation or only due to disruptors that continually challenge how users traditionally transact for goods and services.

Hence, product development needs to stay like a flexible set of muscle fibres — contracting or expanding depending on the demands of the business. One way of managing this is to adhere to a pull-based Kanban model of work that doesn’t specify periods (e.g., sprint lengths) and is purely based on small product development iterations that can be tested in live then removed or tweaked as necessary.

In short, a Product Roadmap is created and baselined over a period agreed with senior management teams. A backlog (direct work items to focus on) is created where developers pick the next highest priority item based on some sort of prioritisation framework used by the Product owner(s) or teams. Incremental development occurs with a collaborative conversation on scope and acceptance criteria.

Features are released into various test environments and placed in a queue of compliance reviews (e.g., PCI DSS change control). Post successful review, the feature is released to market and feedback is sought. Given that there are many ways to manage a backlog and prioritise work, we’ll have to cover this in another post.

Final Words

So far, we’ve covered the following:

1. FOCUS: Communicate your product vision. Over and over and over again.
2. WORK ITEMS: Understand the different types of product development
3. CULTURE: Inculcate principles of Agile; don’t just implement specific templates or frameworks
4. WORKFLOW: Use a pull-based system where changing priorities are welcome.

In future stories, I’ll attempt to cover roadmaps in the context of payments, and some ways to prioritise your work so you can have fewer headaches and more constructive conversations on things that matter!

Did the above resonate with you? Do you disagree? Leave a comment below, and I’ll do my best to address them as swiftly as possible.

Until next time!

— A