Product Architect | Tech Inventor | Entrepreneur
In a report* by CBInsights, failure reasons such as ‘Non-friendly product’ and ‘Product without a business model’ feature at the top of the list. According to the same source, 42% of the startups analyzed, stated that there was ‘no market need’ for their product, while 17% delivered ‘a non-user-friendly product’.
Other reports, articles and blogs from startup founders, seem to agree that most of the major failure factors are strongly connected to product management.
Product-related risks could refer to both the definition and the actual development/ implementation of Minimum Viable Product. A poorly-defined product, regardless how well-built, will probably fail to solve the problem and deliver value to its users. A poor implementation of a well-defined product, will also fail to create value to the user.
Startups need both great product definition (the right focus, connection to the real problem, an MVP addressing the actual user needs and pain-points) and great product execution (agile engineering, right priorities, quality, great user experiences) to succeed.
Based on my experience with startups — I would identify the following as the top product execution risks:
Engineering-heavy startups tend to put more effort than needed on the technical aspects of the product; while it is great to achieve engineering excellence, over-indexing on such technical aspects — at an early stage — might come with additional costs: consider the missed opportunity from features that didn’t make it to the market due to prioritization for purely engineering work. I’ve seen startups putting extra effort into sophisticated super-scalable infrastructures only to get a few hundreds of users when they finally launch the product.
When in an ‘early startup’ mode, you need to have the ability to build features fast and release frequently; this way you can learn from user feedback, adapt and iterate; at fast pace. Normally, scalability, concurrency and related architectural concerns can wait — as it might be more important to deliver additional features to your early customers than a sophisticated back-end to support theoretical traffic and growth scenarios.
To address this risk, you need to apply wise feature and task priorities and ensure that you are intelligently utilizing all the resources you have, in the right order and focus.
When you are passionate about your product, you need to be open to all feedback — and especially the negative signals and criticism: do not allow confirmation bias to affect your judgement — it’s easy to get destructed and focus on positive comments which simply confirm what you want to believe.
To ensure that you are objective, you have to become data-driven — introduce the right product performance measurement framework to help you understand the performance of your product — the patterns and the dynamics; the real user engagement levels; what they like and what they don’t; and why.
There is always the ‘risk’ to get enthusiastic about ‘just in time’ ideas or features; and this is great, as soon as you manage to retain the right focus. The actual risk comes into play if you fail to maintain good prioritization — in this scenario you might end up disrupting your product backlog and the current execution. To avoid this risk, you could append all these new features ideas, to a queue of features for consideration. Then, re-apply your strategic feature prioritization logic, while trying to avoid disrupting product execution towards your MVP.
Modern product development can help managing the above risks, by setting the right focus and leveraging agile engineering practices.
You can manage the above-mentioned risks, by properly defining your Minimum Viable Product (MVP) and executing according to agile engineering principles. The process of MVP definition must start with a clear, solid articulation of the problem you need to solve: begin by framing the problem and attaching the right context — insights describing the market, the impacted users and the competitors.
Having clarity about the problem, the involved users and the the market allows you to generate ideas which could evolve to potential solutions. Clarity for the solutions is also key; consider using Epic user stories and low-fidelity wire-frames to summarize how it is addressing the problem; visualize the key user interaction scenarios and attach high-level technical information — for instance, architecture diagrams of the components and the processes involved. You can then prototype your solution/product to test its potential and validate your assumptions with real users.
Modern product management is based on experimentation and feedback loops — learning from your end-users and improving your product, continuously. One of these build-measure-learn cycles could refer to a prototype implementation.
Building a prototype, to test a concept with real users, is a great idea — provided that prototyping is fast and inexpensive. Also, the prototype will only generate real value and insights if there are big unknowns regarding the product — significant questions to be answered and hypotheses to be tested; otherwise it might only confirm what you already now. For example, you should consider a prototype if the technology involved in your product definition is not proven or it is not highly adopted; or when the solution is defined on top of multiple assumptions.
Testing a concept or a feature via a prototype should not be seen as an isolated activity: experimentation needs to be at the core of your product development culture — an effective way to improve your product and create value to your users.
Of course, prototyping/ experimentation is not the only way to learn from your users. As denoted in the diagram below, each of your releases uses feedback loops to provide user insights and engagement metrics: modern, digital products, use instrumentation and telemetry to capture detailed user interaction data, while it is very common to embed feedback forms and customer satisfaction measuring features such as the Net Promoter Score — NPS.
A key role of a modern ‘product management function’ is to systematically process and interpret this feedback and usage data, to convert them to actionable insights and knowledge about the product and its users.
This allows product managers to better manage the product by accurately measuring success, setting the right priorities and steering the overall development process; to define what to build next, when to prototype and when to run A/B tests; to refine the product strategy and ensure a fast and smooth execution, with frequent releases and no disruption to the users.
Whatever the actual title is — Product Manager/Architect, Chief Product Officer etc. you need a Product Leader in your team — one with a bold vision and deep understanding of the opportunity and the environment.
Your team also needs a wide range of product-related skills and competencies — including deep technology understanding, product sense and agile product development expertise; you need members with the ability to prioritize strategically and use data to make informed decisions.
If you don’t have and cannot afford someone with this profile in your startup, make sure you educate your team to master at least the basic principles of agile product development, feature prioritization and experimentation.
Cover image: pixabay
Level up your reading game by joining Hacker Noon now!