Thirteen FAQs to simplify and speed up your startup project

Photo credit: dkalo (CC BY-SA 2.0)
Greg and I were talking on the other day about how we usually review an idea. It could be a feature implementation, a bug fix, or an UI improvement. When the idea is generated by ourselves, our team, or customers, we tend to ask some questions to validate the idea, other question are here to simplify the solution and clarify some technical details:
- What assumptions we are making here?
Are there too many assumptions that make this task a high risk? Even if it doesn’t work do we know which assumption is wrong? Are there any assumptions we made that we didn’t realized? What do we measure to test the assumptions and what can we learn from the results of the test?
- What is the single biggest pain point we are trying to solve?
Are we spending time to solve a problem? Is it worth solving? Is it really the biggest problem, or are we addressing a symptom and not the cause?
- Does it improve our metrics or contribute to growth?
Everything should improve our goals which are tracked using some measurements. If it is just apple polishing but not moving the needle towards the target, why bother?
- If we do this, who benefits and how?
Are we providing a solution for our targeted users (or segment of our users) needs?
- If we don’t do this, who get hurt and how?
This may be more important than the previous question. Sometimes users are suffering with the existing product. The faster we solve it, the happier they are.
- Is there a faster way of doing this?
Have we thought of all options? Is there a simpler and maintainable way to implement this?
- If we don’t have enough data to make this decision, how can we gather the data?
Let’s think of more paths to research. What is preventing us from getting the data we need and how can we get around this data block? Are there complementary data points where we can extrapolate data to help us with a guided decision. Not everything can be exact, but we should try to gather enough information so that we can make an informed decision rather than guessing.
- Now we know the pros. What are the cons?
When we want something to get implemented, we always thought about the benefits we gain from doing it. Keep in mind that everything has negatives too. To make a objective decision, we need to know the CONs too to be able to make the right decision.
- Can we make this in N weeks iteration? What do we need to cut to achieve that?
Can we make this in time? Time constraint encourages creativity, when time is a factor in analysis, it can lead to thinking up alternatives that would not normally be considered. Can we do less but achieve the same objective? A long interation cycle can result in the same end product as a short iteration cycle, except with more polish that doesn’t help move the needloe towards the goal.
- Can this architecture be simplified and extended later when needed?
Often we may over-architect to accommodate something that may not be used in the future. This is potential wastage. There is no point in investing into something now which could be delayed until the future, or not even used. It means it is possible to release sooner, smaller and lighter. - Can we avoid this code/automation and test the solution manually with human?
As an engineer, we always think programmatically and believe automation is always faster than doing it manually. But what happen if the solution is not applicable before we can cover the cost? It may be more cost effective and time effective to test manually rather than spending the time and resources to create an automated test solution. Will creating the automation test cause a delay in releasing? Will it move resources away from developing the core product? It maybe faster to run manual tests over several releases before an automated solution is ready, even then, the product may already have evolved past the point of the usefulness of the automated tool.
- What’s your time estimation?
Have you thought out the scope of implementation? Do have an idea about how long it will take and can it fit into the timescale of this iteration cycle? - Anything more we can remove from this iteration?
Are we adding something unimportant? Unimportant is anything that doesn’t help to move that needle!
What are your FAQs?
31 notes
-
downontheupside likes this
-
walkrun posted this
