“A software person isn’t necessarily a developer. It’s anyone who, when faced with a problem, asks the question ‘how can software solve this problem?” – Jeff Lawson (CEO Twilio)
It’s because being a software person is a mindset. It’s not a skill set. Software mindset starts by listening to customers, rapidly building potential solutions to their problems, getting real feedback and then constantly iterating to improve. With this constant progression, anyone can apply a software mindset to solve more and more of the world’s problems. To truly survive and thrive in the digital era, either as a potential disruptor, you need to think like a software person.
But sometimes, developers are given solutions, not problems to solve. Developers in these cases are given detailed features, looking like a specification document. These features are detailed with requirements and acceptance criteria from business, UX designers, enterprise architects, solution architects etc. which eventually set the expectations on the developers to just write code to fulfil these requirements.
Now they are separated from the end-users who will actually use the software. Their performance is evaluated on how fast they can delivery features without fail. This could eventually lead to creation of code that becomes clunky, error-prone and above all, misaligned with the actual use case. Not only that, writing a code feels like forever because of the lack of passion and intuition.
The ugly world of Feature Factories:
With more refinement done on a higher level, development has been come a factory, pumping out features, and the team are just line workers. They’ve become disconnected from the business value derived from their work. They finish a feature, or close a ticket, only to get another immediately afterward with little sense of continuity or importance.
Feature factories are incredibly corrosive to morale and, despite the pressure to create an ongoing stream of work, decreases the alignment with the missions of the company. Outputting things is more important than the outcomes those things cause.
Roadmaps & outcomes:
A Roadmap communicates the strategic direction of the company — what are our goals, what are our outcomes, and how will we win in the market. The teams working with roadmaps care about whether the shipped feature has the desired outcome. They constantly make use of tools like user feedback, canary releases, A/B testing etc. to collect insights into how the features are being used by the end user.
How to define product vision and goals instead of focusing on outputs?
The goal of any Feature you ship to a customer should be to change the customer’s behavior in a measurable and positive way. If you ship a feature, and it doesn’t have the desired outcome, you have to agree that, “it was a failure”. In order to know whether your feature worked, you have to know:
what success looks like for each feature
how to measure success
then you need to measure it.
These discussions or vision should be aligned with the development team before starting the implementation or even detailing the feature. The developers may have more creative solution for the problem.
There’s an old story about NASA trying to develop a pen that astronauts could use in space. It was tricky to get ink to flow upside down, and pens kept failing. NASA spent millions of dollars trying to come up with a space pen, until someone realized how the Russians solved the problem—they used pencils. Unfortunately this story is an urban legend, but it still gets told a lot in the software world. Like all good fables, this one illustrates a common mistake—the one where people set out to solve the wrong problem.
The problem NASA needed to solve was not “How can we make a pen that writes upside down in zero gravity?” The real problem was “How can we write in space?”
Comments