While developing our new product Breezi, I don’t think there has been a theme more common that struggling to make decisions without having visibility. Breezi is a product that has thousands of paying users. It’s not the use cases that we were struggling with. It’s how to achieve a new vision that we wanted to fulfill for the consumer version of the product. That vision was “providing intuitive access to flexibility”. We had actually focused on the exact opposite use case before. It was more about limiting control and providing guided decision making.
After we finished our last version a few months ago, we finally realized what kind of tool we wanted to build. The problems was that the UX decisions to pull of this kind of experience is very uncharted territory. Uncharted in terms of all disciplines of product development. It was a very painful process but we’re coming out the other side… I’ll be posting more on that soon. The release is happening in February to a close beta list of a few thousand people. If you haven’t signed up yet, you should go and do that to get on the beta list.
When you’re building a new product with a long development cycle (assuming that you had no other option), you must accept that you’re going to be making a lot of stupid decisions that have no basis. Your job is to reduce that as much as possible by being aware when you’re working on something just because you find it interesting.
You have to get visibility into the impact value somehow.
Many designers that I’ve worked with have no concept of the relative impact value of their decisions. They basically don’t know what they should focus on first. Sometimes that’s good but most of the time, you’re diving into a horrible black hole (because you find it interesting) and if you’re in the design / management function of product development, you’re going to drag the rest of the team with you. That’s selfish and really unproductive.
So my advice is to understand where you have the most visibility / impact value and focus on that first.
If you have to solve issues that you don’t have visibility into -> prototype. Keep prototyping until you understand what’s going on. If you can, don’t tax your main product team with this. Use someone else to prototype. Use another firm. Another dev… anyone else really. Lack of visibility is your problem, not theirs. Solve it before you confuse them too.
A naive / overly ambitious designer or product manager can destroy products. I’ve done it myself plenty of times. The results are horrid. People usually write it off as the expense of doing experimental things. I say it’s a really dumb way of managing resources.
