There are times where the primary question isn’t financial, but feasibility. We may not know if what we propose is within our capability to accomplish. In such cases, identifying the pieces that we cannot estimate is as important as estimating the pieces we can.
TinyToyCo used lean-start-up techniques to find market fit with an online game and mobile app. Now they want to venture into physical product development.
TinyToyCo and the Robotic Cat
"What if we broke free from the boundaries of the phone?"
Pat looked puzzled. "What do you mean, Chris?"
"What if we created a robotic lap-seeking Fluphy Kitty™ toy?"
"Oh! Wow, that would be great. Do you think we could do that?"
"Let’s try to figure it out."
Chris and Pat started listing the behaviors they wanted the robot cat to have. These behaviors already existed in virtual form in the web and phone-app versions. They had the cat-like logic pretty well covered. It was the interface with the physical world that was the puzzle.
"We’ll need to detect the presence of humans, so Fluphy Kitty™ can seek them out. Just doing that and getting underfoot would be a good beginning."
"If we can determine whether the person is sitting down, and make the robot cat jump high enough, it could jump in their lap."
It’s easy to get carried away planning something. But can you really build it? That’s when caution is prudent.
Caution Sets In
"Before designing our own robot, let’s buy a robotic cat toy and add some franken-features to it to explore the possibilities. First up is infrared video to detect the human."
"And then jumping. If we can’t get jumping to work, then the lap-seeking feature isn’t going to work."
"Before jumping, I bet we could do clawing on the leg."
"I think we’re going to need some specific robotics expertise. This is a lot more than our experience can handle."
"You’re right. But we don’t want to go deeply in the hole on this. Our current products are generating income, but not so much that we don’t have to watch expenses."
"We’ll set a budget on each physical capability. I think we can estimate the costs of integrating the capability and tuning the realism of the behavior based on our experience with the virtual cats."
The principles are simple. Estimate what you can based on past experience. We’ll look at that more in Chapter 2, Comparison-Based Estimation. For the unknowns, you have to set a budget on how much you’re willing to spend to see if it’s possible to do what you want. Validate those budgets as early as possible.
If you reach a budget limit on an item, you need to stop and replan. It could be that you feel you’re close enough to budget a little more. It could be that you’ve come in under budget on prior items, so you’re willing to spend a little more on this one. Or it could be that you want to rethink your plans altogether. Maybe you need to drop this particular capability, at least for now. Can you still move forward toward your vision without it? A lesser version that you can build is worth more than a grand version that you can’t.
And don’t overlook the possibility it may be time to quit and cut your losses.
(See Sunk Cost Fallacy in Cognitive Biases.)
Product development is a gamble. Don’t gamble more than you can afford to lose. Taking risks can become addictive, and you need to watch out if you want to remain responsible.
