Is it a bad idea to include a complex payment mechanism to the product development process for a beta app?

Question

I’d like some advice. I’m busy helping a client ideate an app idea, following which I will start the wireframing, user testing and technical speccing process in an iterative flow. The idea is to ultimately build a beta with a set of core features for testing. They have a somewhat elaborate monetization strategy which they want specced and built off the bat, which I am somewhat uneasy about as I believe the initial version should exclude that and just focus on the core functionality. Thoughts on this?

If I go with what they want, It will increase the scope of what I have to spec out and prototype, as well as the complexity of the admin panel which I was hoping to almost avoid entirely for the beta. This obviously means I can bill for more hours but my uneasiness comes from wanting to do too much all at once vs staging each milestone and focusing on one thing at a time (ie building and testing efficacy and acceptance of the core features, implementing user and Q/A feedback, then moving onto planning, designing, testing, speccing, and ultimately building in monetisation mechanism which is core to their business model obviously but not core to the usability of the app in my opinion).

PS. My product management experience is limited in that I’ve never done it for other companies; just my own startup as much to ‘the book’ as possible with the time I have available.

Answer 1

TL;DR

You perceive this as a scope problem, but in all likelihood the underlying problems have more to do with how you visualize the work, how you collaborate with your development team, and how effectively you set the expectations of your stakeholders.

You should adopt an incremental, iterative approach that allows you to deliver features in almost any order. I provide some examples below of how this might work in your particular situation.

Prioritization, Vertical Slices, and INVEST Critera

As a Product Owner, you have the power to prioritize features in the Product Backlog to meet business requirements. If the customer wants to prioritize payments, then the right thing to do in an agile framework is to work with your development team to create a vertical slice of functionality for that work, and to make that the top priority.

As an example, you could use the INVEST mnemonic to create a theme around payment processing. The user stories in the theme would all center around payments, and the team would then wire up just enough features to deliver the business goal of accepting payments. The application might not even do anything else, but it would have a potentially-shippable payment feature that could be integrated into future product enhancements, or refactored and refined as the product evolves.

You might have some backlog items like:

As a user,
I want to be able to check out a shopping cart
so I can process my order.

As a user,
I want to fill in the credit card fields on the order form
so I can pay by credit card instead of with cash.

As a credit card processor,
I want the payor's billing address
so I can process the payment using address verification.

As an payment processor,
I want an order number to associate with a credit card charge
so that the order and the payment can be reconciled.

These stories form a theme. Anything that isn't truly essential for the theme can be stubbed out or left for future phases. As just one example, you might be tempted to flesh out the shopping cart beyond what's strictly necessary for this vertical slice. Pragmatically, all you really need for this set of stories to meet a reasonable Definition of Done and be demonstrable to stakeholders is:

1. a "Check Out" button that provides an order number to the payment processing backend; and
2. a payment processing backend that can be validated against the payment gateway's API (preferably in some sort of test mode).

Approaching the problem in this way allows you to meet the customer's needs and priorities without going overboard. Don't fall prey to the mentality that you need to build an entire hotel so you have somewhere to put an ice machine, when the core requirement simply says "I want a cold soda."

Create Minimalist Features

Features should be small, testable, and relatively independent of one another. As a Product Owner, you work with the stakeholders to identify the business priorities, and with the development team to identify "the simplest thing that could possibly work." A good development team will collaborate with you to identify minimalist core features, and help you pare away non-essential implementation details that allow you to build the product incrementally and iteratively.

Agile frameworks embrace change by accepting a priori that a certain amount of scope change, rework, integration-related refactoring, and other additional effort will be required over time as the product evolves. This is accepted in exchange for the ability to deliver vertical slices of functionality in almost any order to meet today's business goals, while retaining the ability to adapt to changing goals and requirements in the future.

Embrace Emergent Design

Customers have a need. You provide the vision by focusing on what, not how. Then collaborate with your team in a way that doesn't over-constrain the solution space. Give them goals and boundaries, and then turn them loose so that they can apply their subject matter expertise to the problem at hand, often in ways you might not even be able to imagine at the start of a project.

Answer 2

I don't think there is a "correct" way to do it. If the client wants to see the payment feature in the beta, then they want to see it. There is no project management method to tell them otherwise.

I can understand your wish to take small steps, but that just means you will need to build the beta in small steps (i.e. features first, payments later). If the client wants payment in the beta, it will be in the beta. When you build that beta, it might be step 5 in your 5 step process, but it will be in there, because the client wants it in there. Best case is you show the client milestones or iteration results in regular intervals and they will see that they don't need the payment feature when they see step 3 or 4 working. But that's up to them.

Make sure your requirements can be met in steps and that those are prioritized (whether you call it an Epic, Sprint Goal or Milestone is not really relevant). But if the client prioritizes payment higher on that list than you like, that's their right, they pay for it.

---

Sidenote:

monetisation mechanism which is core to their business model obviously but not core to the usability of the app

Maybe to better understand them: their company will be in business with an app that people curse about because it's missing UX features, but they will be out of business if the monetisation scheme fails. You cannot blame them to set their priorities in a way that keeps them in business instead of in the hall of fame for "greatest UX app that ever failed".