- Do we deeply understand the customer’s problem? why they want us to build the feature in the first place. Have we looked at how the job is done currently, remember the job is often done without software?
We really need to role play everything in the design before the build stage to ensure that we are developing a solution that solves our customer’s problems. It is critical that we role play every feature in person, in front of a whiteboard, with a simulated account, and with input from customers, customer success, and sales. Think like the customer. Measure twice cut once.
2. Does the feature/bug qualify as a tidy-up that can be fast-tracked? Can we quickly estimate how long the feature will take? Do a quick cost/benefit analysis and get it moving? Kaizen – Continuous Improvement.
3. What is the absolute lightest version that we can build without limiting functionality? After we have thought it through, what can we take out? Remember 80% of all the benefits come from 20% of the work that we do. We need to always try to find the smallest coherent solution. Starting small allows us to ship sooner and we learn when we ship. Also shipping in bite-size chunks makes it easier to spec, build, test, and deploy. Always avoid unnecessary bells and whistles.
4. Is there designs/code that we can repurpose? Standard and repeated design and code make it faster for us to build and easier for the customer to understand.
5. Have we looked at how the competitors do it? Remember our competitors have ALSO had to think deeply on how to solve these problems.
6. What are the technical long-term implications of the work? Will it slow down the response times, will the feature affect another part of the app? How will it affect current users and future users etc?
7. Is it super easy for the customer to understand, how can we make it easier. Are we using their language? Can we prompt the user in-app? Is the customer in full control of what’s happening, we should never build anything that means the customer has to ask us, “how did you get here?”
8. Are we sticking to the fundamentals. Are we following established best design practices?
9. Always avoid overly clever solutions. Innovate where we differentiate and copy everything else.
10. Happy customers and what we ship is all that matters not designing over complex processes, not the number of lines of code that we write, not rushing to get something into dev.
—————————————————————————————————————————
Always leave room for flexibility. Do we move a feature up the road map, (Ie. is it a priority for a customer, is there someone currently working on the same part of the application that we could bolt the feature on to???
Move Fast but Don’t Break Things
