The Icy Truth About Product Complexity
Simplicity & Focus. They are the current buzz words in our product meetings at Apply.Property. People often pitch me business ideas, and clients often request features. In these discussions I always want to get right to the core. What is the one key thing that they want to achieve. What's at the very heart of their need.
There is a brutal reality in life, it's actually very hard to get one thing done, and done well. Complicated systems have usually developed over a number of successful iterations. Where one thing was done well and then added to.
I'm obsessed with clarifying what we as a business are trying to achieve, simplifying it to one goal and then staying focused on delivering that goal.
There is a reason this is so important. One simple, clear goal is very hard to deliver. That goal is the tip of a huge iceberg, There are layers upon layers of hidden complexity within product.
Incase you don't make it to the bottom of the post I've put the summary here.
To summarise one small feature request, or one little change has to go through a mammoth process. It needs:
planned
sense checked internally
sense checked with clients
designed in detail
thought through again to ensure all states are present
planned for development
built
tested
fixed
tested
fixed
tested
fixed
and then tested again...
Product complexity is exponential, adding more at the start of the process creates a huge amount more work at the end of the process, particularly in the testing of a large and complex system.
A couple of examples where we messed up here: user profile pictures, facebook login, property descriptions, property map display. All of these could be argued as 'essential' features but they are not. The core product can function just fine without them. Simplicity and Focus. Stripping back all features to the essential part at the planning stage hugely reduces build cost and time. This is vital, particularly if your start up is at risk of building something that does not have a proven commercial case...
The analogy I like to think of is a hot air ballon. You're over the ocean, with so much gas in your tanks (funding) you have to throw EVERYTHING out that is not essential, otherwise you're going to run out of gas, crash, and drown...
We start with some getting ideas down on a pen and paper. What should happen what does the tool do, where can the user click, what actions can be taken?
This then gets turned into a slightly more sketchy wire frame. There are loads of good digital tools for wire framing but I find it fastest to use a pen and paper then play around with copying and pasting bits and bobs in preview.
Great we have a basic idea of what we want to build. It's then time to make it pretty and sense check with customers. A step that many companies completely miss. Once we're pretty(ish) sure we need to build the feature, the real work starts.
A graphic designer needs to take the sketchy hand drawn wireframes and turn them into palatable designs that are linked together on a UX Map.
These designs will change based on different states, e.g. if a button is clicked, or a page is loading, so we need to start thinking how everything looks in detail and to create a UI Kit.
The little feature idea has now taken up a significant amount of time, it's been thought through, tested conceptually with clients, professionally designed in detail. It's now ready for the heavy lifting, development can begin.
We use a tool call Pivotal Tracker to log development work. In building inevitably things we didn't think about in planning come up.
After building.... (a lot of building) we have a live product! Easy, job done... Not so! We're maybe half way, this iceberg has still got a lot of work to left in it.
It's now time to test the product. This involves writing a large number of test cases and checking them. This is a LOT of work. There are a huge number of variables to test. How does the product look in all browsers? How does the product react when the browser is offline? Every part of the site and every process needs checked.
This bug fixing process is iterative. Often when one bug is fixed then another part of the site breaks. Think whack-a-mole. When bugs are fixed, the entire product needs tested all the way through to ensure nothing else has now broken as a result of the fixes. Its a lot of work.
