Building A Digital Product: Part I

There used to be a time when building and launching a digital product was a straight forward affair. The steps were something like this:

  1. Start with a rough idea of what you were looking for
  2. Find someone who could design and build it for you
  3. Find people who would help you run it and go live.
  4. Find ways to market the product.
  5. Find ways to sell the product.

Other than the really big players, most of the regular Joes would handle most of the steps on their own or, in some extreme cases, handle all the steps on their own.
In the last five to eight years the steps have been shred to bits, thrown out to the dustbin and replaced with a set of steps that bear no resemblance to the earlier ones.
Most of this disruption can squarely be blamed on mobile computing. The revolution that started with telephonic devices being able to access bits of textual data (read SMS), was turned on its head when the same devices were transformed into data devices that could also do telephony as one of the many things it could do.
The other significant development that has caused the playbook to be thrown out is the commoditization of many of the moving parts that are used to build a digital product. From databases, to job queues, to logging, to any other part of the technical stack, finds an array of plug-and-play software service platforms that a new product can leverage from day one.
In the early days, teams had to develop everything — from email subscription systems, to delivery systems to, logging infrastructure — to get going. With all these new services, product builders are less builders and more integrators these days.
While this has created an entirely new universe of opportunities and possibilities, it is also responsible for creating a lot of confusion for companies and individuals looking to build products.
What this series will attempt to do, in the first part, is to bring some structure to the steps and elaborate on the steps a bit with an aim to reducing the amount of confusion in the market regarding the steps.
I have no illusions that this will be a definitive list as there are parts of the stack and ecosystem I am completely unaware of. My idea is to fill in the gaps that I can and I’ll be more than happy to bring in suggestions about what else can I cover here.
I am going to tackle the more technical aspects in this post:
Design: Designs are best approached first with storyboards. The story boards are used to create process flows. The process flows lead to wireframes. The wireframes lead to the final design.
You can skip all of the steps and go directly to a design, but the odds are that you will struggle at a later stage to force fit that disciplined a process into an existing system that has grown without it.
What is more important — short term gain or long term pain — make your pick.
Development: The choice of framework/language to build on is made at this stage. Unless you are someone who knows technology very closely, avoid using the latest fancy framework in town.
You have to establish coding standards, documentation standards, bug tracking, version control systems and release management processes.
Testing: Set up both automated and manual tests to address both logic and real-world usage. Testing infrastructure built right will include a good set of unit and behavioural tests and a continuous integration framework that will catch most errors during the build phase itself.
Deployment: No (S)FTP. Simple. Deployment options are available these days from the simple, to the ridiculously complicated. It gets harder when you have to update code on a pool of application servers that need a rolling update/restart cycle.
The more challenging part in this is to abstract away this part of the stack to a simple interface that the developers can use. You cannot and should not expect developers to debug problems in the deployment infrastructure.
Distribution: A local CDN or an international one — which is the right one to use? Should I use a CDN at all? Recently, a company that I spoke to had a response time to their origin server that was 1/5th of what they were getting from their CDN. This was done to leverage cheaper CDN bandwidth and is a classic case of cost optimization at the wrong place.
Is Couldfront the right solution? Can my preferred CDN provider handle wildcard SSL termination at reasonable cost? How costly is it to do a cache purge across all geographies. Is it even possible? Is it important to purge CDN caches? Is a purge important to avoid compliance hurdles for some obscure requirement in my market of choice?
Mobile-specific Parts: Native, cross-platform or HTML5? Do I need a mobile application at all? Which platforms should I target? What is the minimum OS level that I should support on each of those platforms? How do I align those decisions with the target audience I am going to address?
Outbound, non-consumer-facing Services: Should I expose any of my internal data with a developer-facing API? What should I use to expose that API? Do I build it own on my own or do I use a hosted platform like Apigee? What sort of authentication should I use? What sort of identity management should I use. Should I even try to split identity and authentication as two different services?
Inbound, non-consumer-facing Services: What do I use to handle data that I fetch from other sources? How do I ensure that I cache my requests to respect rate limits. What is a Webhook? How do I go about implementing one?
Replication & Redundancy: What is the maximum acceptable downtime for my application? Is there a business case for a multi-DC deployment? How extensive does my disaster recovery plan have to be?
AWS, Rackspace, good old dedicated rack in a datacenter? Should I use Glacier? What should I use for DNS management?
Analytics & Instrumentation: DAU, MAU, WAU — what all do I have to track? Are bounces more important than acquisition? Is acquisition more important than repeat transactions? How do I bucket and segment my users?
How do I measure passive actions? Should I start tracking a minor version of an otherwise less-used browser as my javascript error tracking reports are showing that the current release is breaking critical parts for my most valuable demographic who use that exact obscure browser?
Wait, I can track client side javascript errors?
Conclusion
As you can see, the list raises more questions and provides no answers. This is intentional as there is no one-size-fits-all answer for these questions. Even within specific company lifecycle segments (early stage, stable start-up, established company), the internal circumstances vary from company to company.
These list is more a starting point than a destination in itself. Use it to build a better framework that is suited for your organization and your product. And if you need more help, just ask!

Never mind.