We often talk about putting the customer in the center, and starting with the customer needs, but how often do we REALLY let an actual customer tell us what to focus on? Many of us think that we know what the customer wants, andwe spend many hours discussing back and forth in meetings and by showing internal demos to convince each other that we are right. My advice is to stop all of that, because it’s just a waste of time. I have seen over and over again very careful estimations about what customers want turn out completely wrong. So instead put time into mapping the customer journey, preferably together with real customers, and then try it out with more real users.
Another fatal mistake is to try to please every customer with a single solution. Customers are different, with different needs, and it’s simply impossible to please them all with one solution. If you try to please everyone, you will most likely end up not pleasing anyone. If you have been in markering, IT or product development for at least a couple of years, you know this is true, but still we continue to do the same thing. I suggest you start with a real customer that has an actual need, and then try to solve that need. It sounds simple, but it’s actually really hard, because it’s so easy to be distracted by everything (cool) that you would like to add, but stick with satisfying that single need in the best way possible, and when you have validated it with many users, you can start with the next need.
My experience as an architect is that when you involve real customers as early and as frequent as possible, you get an excellent opportunity to learn the real truth. You get to see the expectations of actual users, and it will most often completely blow you away. They will lead you into new ways of thinking, even about fundamental assumptions that you made, and you will feel a new kind of humility towards your limited insight. The earlier you start, and the more real customers that you involve the better. Let them try out new things as early adopter (or as we prefer to call them nowadays: beta user), carefully listening to their feedback while giving them benefits, and you will grow a group of very important users (what Malcom Gladwell in his book The Tipping Point called connectors, mavens, and salesmen) that will support the larger community.
Many of my fellow architects share similar experiences, and that is why we agreed on the following general principle:
Instead of trying to meet everyone’s needs, creating
something that no one wants, we design a usable service
to support an actual need.
It’s something we strongly support and promote, and therefore it has been included in our Architecture Manifesto.
It’s also reflected in one the of the core values of the manifesto:
Focus and refactoring over detailed architectural design
I will get back to the refactoring part in a future blog post.