‘I want a unicorn! Get me a unicorn!’ (Painting: Virgin and Unicorn by Domenico Zampieri)
One of the most dysfunctional question a technical specialist needs to answer is “is this-and-that feature feasible?”
The problem is that by asking a technical specialist is this-and-that feature feasible, you most likely increase the amount of fiction more than the amount of knowledge.
What a technical specialist should answer? Feasible in what sense?
- Usually a technical specialist does not know the feasible budget for implementation. Technical feasibility is not independent from financial feasibility. If there are no shared conception of the economical constraints or expected return on investment (ROI), the estimate of feasibility most likely depends upon the previous projects more than customer needs.
- Feasibility of whole is the goal, not feasibility of single details apart from the whole. Instead of estimating feasibility of a features, one should estimates how much effort it requires to implement first version that delivers some value.
- It is hard to say if something non-trivial is feasible to implement without experimenting a bit. In theory, everything can be done if you only have unlimited budget and no schedule. The question is not if something is possible but if it is easy enough. That is the harder question of the two.
- It’s unclear to whom the feature should be feasible. For a rookie team even relatively easy component is not feasible.
Unicorn option 1. Relatively cheap and small. Narrow usability. Lifetime costs: low. (Image by Emre Ayaroglu)
Unicorn option 2. Expensive and big. Versalite usability to many. Lifetime costs: high. (Image by Yottanesia)
What to do instead?
Here is my roadmap toward better match between the concept, economic constraints and the technical feasibility of the concept:
- Start with why instead of what. It is rather easy to ideate what there could be, but if you forgot the goal, asking about feasibility does not make sense at all. My personal favourite method for this is Gojko Adzic’s Impact mapping, but there are other methods that also create path from the goals (‘why’ we need a solution) to possible solutions (‘what’ there is for a users) via users (to ‘whom’ the solution is for) and user’s actions (‘how’ an actor goes toward ‘why’).
- Build culture of trust and willingness to listen to others. There seems to be an attitude stating: ‘If you know how to do it, you cannot understand why would you do it and vice versa.’ This attitude is not only cynical, it also makes conveying information over the boundaries of expertise far more difficult. Open and fertile communication start with trust and willingness to listen to others.
- After the first two steps, you need ask no more if a feature (‘what’ there is for a user) is feasible. You can go deeper and ask: (a) What is the simpler solution to the problem relating the goal? (b) Is the possible more advanced solutions worth of the extra cost of implementation comparing to the simpler solutions? (c) What are the riskiest parts of the solution and in the implementation of it?
Did those options match to your need for a unicorn? If not, don’t waste your money on them. Some dreams are not yet ready to be implemented, and that’s okay. They are still source of innovations. (Image: Smoking Lady by Robert van der Steeg)
If after phase 3 there seems to be a high chance of big gains within reasonable economic risk, just do it. If not, don’t do it. Do the last check regularly and prepare to kill an unfeasible project before it drains you.
To sum up
Don’t ask about technical feasibility of features, ask for simplicity. In practice:
- Crystalize the need and the expected benefits. What is the main useful function of the feature? What for the features is really needed - and what for it is not needed?
- Clarify the options. What are the options in achieving this? Which of the available options looks the most attractive in terms of effort and impact?
- Do it, or don’t do it. There is no try. Is the most attractive option attractive enough to pursue it? If you find yourself trying anything that could help, just stop and return step one.
You cannot control the costs by ensuring the feasibility of each part of the whole! The best way to control costs is to minimize the complexity of the solution. Controlling complexity is crucial: it helps you to keep the solution as changeable as possible. (See Antti’s text on the importance of changeability.)
After this you should ask: Did the solution really solve the problem well enough? Was the problem correct in the first place? These topics are out of scope this time. If you want to know how, keep on following this blog.
Ari-Pekka Lappi is a hybrid philosopher-engineer. He has over 10 years of experience on software development in various different roles, especially as scrum master, developers, solution architect. He has published articles on the philosophy of games and has graduated from University of Helsinki majoring Theoretical philosophy.
- Author
- @ilmirajat
- Interview