The harder a project is, the prouder we feel about it
The Study: Ariely gave origami novices some paper and instructions to build a (pretty ugly) form. Those who did the origami project, as well as bystanders, were asked in the end how much they’d pay for the product. In a second trial, Ariely hid the instructions from some participants, resulting in a harder process — and an uglier product.
The Results: in the first experiment, the builders paid five times as much as those who just evaluated the product. In the second experiment, the lack of instructions exaggerated this difference: builders valued the ugly-but-difficult products even more highly than the easier, prettier ones, while observers valued them even less.
The Upshot: Our valuation of our own work is directly tied to the effort we’ve put in it. (Plus, we erroneously think that other people will ascribe the same value to our own work as we do).
How does it apply to Software Development?
How many times we spend years, pouring our heart and soul building software (our origami), only to find out that others are not finding it as valuable as we do?
If you read Ariely’s experiment, then you might understand by now that your developers completely fell in-love with their amazing architecture, that your operations team has a full-blown monitoring system that took months to build and that your product team has a yearly plan with at least 3 months of spec a head of time.
Here is the problem – what will happen when you’ll approach your team and ask them to throw away what they did and “pivot” to a new business? Are we too emotionally invested to see that we built a beautiful origami that no one will pay for?
Companies that fail to learn and adjust will eventually run out of money and people. This is why it’s so important to change the way we value our execution team, and set our expectations differently from what we used to.
Strive to build an organization which values learning over building
“Lean startup” created a huge impact that not enough existing companies fully understand and utilize. More specifically, not enough managers and leaders leverage the fact that “Lean methodologies” change the focus from just building things to building the right things, by asking these questions:
- Do we solve a real problem?
- Do we have customers who find our solution useful?
- Can we make enough money to make our solution a sustainable business?
Execution value should be equal to how fast we’re able to learn and adjust
As an execution team (i.e. everyone involved in releasing the product), our job is not only to appreciate well-crafted software, but also to understand if it makes sense to invest so much in every step of the way. We need to enable faster learning by breaking apart our solutions into smaller steps while measuring their need/usage as we release small deliveries to our customers.
Here are a few questions you should ask your execution team more often:
- Will we know when and how people hear about our solution?
- Will we be able to understand if and how they use our solution?
- Can we change things quickly enough to improve our solution (based on learning)?
- Can we measure the quality (usage) of our changes?
- Can we reduce amount of work and test for need earlier (think MVP)?
Using these questions to set context and priorities can help your execution team to be more passionate about problem they’re trying to solve, and the process they’re using to figure it out, as opposed to being passionate about their current implementation.
When you focus on the problem, it will be easier to change the solution.
Kris Gale (of Yammer) wrote it beautifully: “Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built. “
P.S. did you check my latest side-projects?
1. SoftwareLeadWeekly — A free weekly email, for busy people who care about people, culture and leadership.
2. TeamLeadToolbox — A practical guide for building, growing and mentoring teams.
Photo credit – TED