It’s All About Value

Let’s start with a somewhat innocuous question — “How well does the design of your system map against the value that it delivers?”

A little bit of pondering reveals that this is a bit of a trick question, since it covers a whole range of possibilities.. After all, System is a ridiculously overloaded term, that can refer to anything ranging from Infrastructure (“k8s on GCP!, Postgres! Swagger! React!”), to Logic (“CQRS, with event-sourcing tied into a scatter-gather approach!”), and pretty much everything else in between, above, and below.
Design is equally loaded — is the “low-level” stuff (k8s, Postgres, etc.) actually part of the Design? After all, it could be, if it is going to inform a “build-vs buy” decision for you by, say, making you roll your own database!

That said, the point here is that the question forces you to confront Value, and actually spell out what it means to you. And the process of spelling it out will actually help you make the (hard?) decisions associated with your system design. For example

• 1. What stage of the customer lifecycle is this for? i.e., Which of Awareness / Acquisition / Activation / Retention / Revenue / Referral is it for?
• 2. How much time do you have? Is it 3 weeks? Or 3 months?
• 3. What happens next? Do you need to worry about Future-Proofing? Or is this strictly a proof-of-concept to get the contract?

and so forth. Your product manager can help you work through these questions, and the answers should (must!) help you figure out exactly how much time/energy/effort you need to put into designing your system.

Once you figure this out, don’t forget to document these questions and answers!
There will come a time when you will get the inevitable “Why did we spend this much time?” and/or “Why doesn’t it also do …?”, and you need to be in a position where you can rationalize it. (Hopefully, you’re in a place where the response is “Oh right!”, and not an accusatory “I never said that!” )

Mind you, documenting this isn’t just about self-preservation, and/or reminders. It’s also about adjusting your priors — think “learning from your actions”. After all, you made decisions based on these questions and answers, and it’s worth knowing how well did these panned out!
Broadly speaking, you probably
• Got things right, for the right reasons: Awesome. Unlikely, but awesome.
• Got things right, but for the wrong reasons: Much more likely. Count your blessings, figure out why you got things wrong, why things still worked out, and learn from this!
• Got things wrong: Unfortunate, but a huge learning experience. Post-mortem the heck out of this, and figure out what failed. It’s critical that you figure it out, because if you don’t, you are doomed to not only repeat it, but repeat it often.

To recap, you need to figure out why you are doing what you’re doing, spell it out in as much detail as possible, and then go back and assess whether you got things right.
Which brings us back to Value — the above feedback cycle is, in the end, all about identifying whether what you are doing is contributing to the business goals, and generating value appropriately. If it isn’t, then, well, why are you doing it?