Product Management

July 15, 2020

Here is a question for you:

How would you design a part of a billing system, responsible for calculating the amount that needs to be paid for a monthly subscription?

Specifically: let’s say we sell mobile carrier plans and that there will be a billing plan of sorts that handles the amounts and there will be clients, and you need to figure out how do you manage the relations between those things.

Should it be possible to change billing plan data.. for example the price? What about clients already on a plan? Should it be possible to upgrade or downgrade to another plan? What about usage fees? Should we charge if clients go above what the plan offers or should we just block data until new billing period starts?

That’s the kind of question you could expect on a job interview, and it is in fact something that can happen to you in the real world. The difference between those two scenarios is obviously the context.

When you talk about it in job interview context you are trying to solve it for the ideal world, and so you are mostly trying to uncover the correct solution. The definition of correctnes in that case would of course differ from interview to interview.

When you talk about it in real world, as in: it’s something you have to do, you need to take into consideration information about the environment. You need to answer the following questions:

• What is the budget (how long can we work on it?)
• How long can we postpone the deadline if we have to?
• How many people will work on developing, supporting and maintaining it?
• How much value will it bring?

For example let’s say that the context is:

You are working for a huge multinational company, and this billing system is a key element in new partnership the company is starting

In that case we can imaging answeing questions above with:

• Does not matter - we can work on it as long as we need to - it was promissed for the end of Q2
• There’s only a soft deadline, we don’t want to move it but if we really have to there should be some wiggle room
• There will be a team of 5 developers, 1 PM, 1 designer working on the project; the initial rollout will be handled by the original team after that there will be 1 developer supporting the project (probably each person from the original team will rotate this responsibility)

OK, scenario two:

You are working for a small comapny (20-40 people), this is the billing system that will be used by one of the key products the company is realeasing

In that case we can imagine answering questions above with:

• We have 4-6 weeks to release it. In reality we need this yesterday as this will be one of our main revenew streams that will make or break this company
• Can we have something working next week? What if you work over the weekend?
• The team is bussy on other things so it’s only you. There is no Product Manager but the Project Manager has some time availabe so he’ll handle anything that’s not coding. You will handle rollout obviously but then we will have to move you to this other thing, so we’re hoping there will be no support needed.

Given those two real world context, would that affect the type of solution you’d propose?

How could it not?? In fact it’s even more nuanced than that! In that second scenario the response would be different if any of the attrtibutes of the environemnt changed even slightly.

That is when you should strive for doing the right thing

I am often disappointed how hard it is to instill this simple distinction in some companies. Without some experience and the right attitude it is some times hard to accept that perfect is the enemy of done. For example it is OK in some cases to have those billing plans editable if it means it will shorten the release date from 3 months to 2 weeks, etc. As usuall, it is all about tradeoffs .