Starting with an idea, building an app or a software program, then selling a product isn’t a far-fetched idea. But going from a custom program to a product is a long path and takes determination and patience.
Product Strategy and goals
A product starts with marketing, and marketing starts with knowing yourself.
What makes a product a product, instead of just a software program you write? Start by formulating a strategy and a clear goal. Do you want to build a stand-alone product, a product integrated into a larger ecosystem, or a service (with some IT behind it)? Consider your strengths, or the strengths of your company. Are you an algorithm hero, a data scientist, or is your company enjoying the trust of a very large user base? Do you want to bring your opinion into the product, or let allow others to express their opinion, while remaining strictly neutral?
Start with a rudimentary business plan – keep it simple. Where will your income come from? Where do you spend money? Avoid to start too grand, or too small (too little too late to gain any users). Don’t do an improved version of what is already available – unless you’re very sure that the improvement will change the market.
There are many approaches to Business Planning (I like the Business Canvas) and fast prototyping – but this is going beyond the topic of this post.
Product Mindset, an emotional affair
Coming from custom development (either for your own or for a client), it is quite hard to change from the ”can do” attitude to the “does it fit into the product?” question so typical for the product mindset. This question is so important because you have to find a solution that fits all your clients.
The key is to delight customers with your product. Building and marketing a product is therefore quite emotional; not only will you be attached to the product, the clients will hopefully be too.
You will always carry the product on your mind: The clients’ wishes, how to integrate them without increasing complexity, continuous improvement of all your product’s components.
Paramount to the product mindset is saying “no” to a client’s specific wish, but keeping it in mind until you found a more general solution fitting into the product.
Stay away from the desire for complexity. Don’t make every little feature an option – just integrate it. Have a few major choices, not a myriad of modules (not in the sense of programming modules, but installable parts of the product), each with a dozen optional parts. Every configuration item has a cost: combinations for testing, wrong configurations causing support headaches, training requirements, and market perception of a complicated product.
Think long term: How can you grow, up to 100 times the user base, to 10 times the functional coverage, without becoming 10 or 100 times more complex?
A product should be like a human body, designed for years to grow, change and operate without ever taking it down. Contrasting to this, a project is like an outfit – set up for some time, then replaced. The body is elastic and adaptable; parts change (cells die and get replaced), but it is still the same body.
To build for potential of longevity and growth, try to build elastic software: Solid, extensible, connectable structures, on a strong technical foundation. To do this, product managers and developers must work together, understand each other, and create a common vision.
APIs and structures are important – design for abstraction between every layer, but restrict the number of layers. For each abstraction, be tolerant on what you accept as input (compare to outside temperature and nutrition affecting a body), and very strict on what you emit as output (compare to body characteristics, such as core temperature or blood acidity). Always validate whenever and wherever you define structures; keep definition, validation and documentation together in one place. Document, but do not cast fluid functionality into concrete.
If you can stand on the shoulders of giants, do so! If there are established solutions or structures in your industry, use them [Digital Essence].
Single code base
A product must have a single source code base, not a different source for each customer or deployment option. Customization is ideally done with plugins and configuration. If the application is deployed on clients’ hardware, keep configuration as central as possible. For example, never require a phone or tablet app to be configured for a client before it is deployed, as this complicates deployment and hence weakens the elasticity.
Think testing from the beginning
Complete the product by releasing: While a product is continuously evolving and perhaps continuously being built and deployed, freezing features and code is important as a quality gate and a base line for testing.
Tests exercising the product functionality from end to end are important, and must be automated (otherwise you’ll take shortcuts).Tests should also exhibit elasticity for deviations outside of the component being tested.
Think support from the beginning
If you get a support call, be sure that you have diagnostic information available. Imagine a doctor diagnosing an ill body without a stethoscope or any other instrument. Log the information you will need to answer a support call in the middle of the night. Where do you make critical assumption about conditions that might not hold forever? Can you log critical results?
Your logging experience will grow in the same way as your test base should grow with each bug. The book Release It! contains many examples, hints and tips. It is ten years old (a 2nd edition is being prepared) and opens with an example of a real disaster grounding an airline due to an IT problem.
Rinse and Repeat
Hopefully your product finds enough users and lives long enough to go through many releases. Always apply the same care as you did in the initial construction. Keep it elastic, and trim and replace dead features.
So you want to build a product? Do your homework, build a great product. And enjoy the emotions!