Since the beginning of software development, developers have held the key to building great products. Since Prolific’s inception, we’ve challenged that thinking, striving for a team mentality. We know that it actually takes a very disciplined team of individuals to build a great product. So why is the public perception of software development so individually focused?
The challenge is that, at a large scale, we’ve been trained to work within the boundaries of specific roles, which get mapped to distinct categories of tasks and coordinated from above. This creates a dichotomous kind of work ethic as people think: “This is something I do, that is something someone else does,” or “I only accept this kind of deliverable, and will only deliver that kind of thing,” or “I’ll do what you tell me to do, or I won’t do anything at all.” At best this is an innocent attempt at efficiency, at worst it’s a system of selective ownership and blame.
At Prolific, we wanted to try something new. What if members of the product team were able to do things that weren’t necessarily their expertise? Should only developers have access to writing code? Should only the designers have access to Sketch or Photoshop? Should Product Managers be the only ones to prioritize features and write acceptance criteria?
Is our ego, as designers, developers, and product managers, too big to think that other disciplines can’t help us help us do our job? F*ck that.
At Prolific, we try to be more as a team. Product Managers can pull the latest code from the repo and run a build to test acceptance criteria. Product Designers open up Xcode and push pixels to perfection. Engineers use Photoshop or Sketch to slice assets.
The way we think about building the best product possible is to spend as much time as we can solving authentic user problems and driving real value to those users. We would never have the time to devote ourselves to the user in this way if each of a product’s team members were only focused on what they were “supposed” to be doing. People would often be waiting on others to complete a certain task that could be tackled by another team member with more free time. This results in a lot of unnecessary blockers and a slower building process. More importantly, however, it fosters an environment that implies we only trust our team members to do exactly what their job title entails. In reality, we know the people we hire are talented enough to do more.
We’ve entered the age of the “T” shaped person, one who is proficient in a particular area but can also rove between other kinds of work in order to increase the effectiveness of the teams they work within. These kinds of people, and the environments that enable them, allow teams to be resilient to change and uncertainty, which is the norm for our kind of work. This is counterintuitive for some people, because it seems to decrease the efficiency of the individual, but this is not a concern if your focus is on the team’s effectiveness in solving problems.
Making a product can’t work like a factory, as software has been looked at in the past. If each individual only completes the tasks directly assigned to them, it hurts the entire team. It’s not practical to complete only one task and then pass the project down the line: everyone is moving down that line together. Maybe it’s not even a line at all.
A Fearless Mentality
Although it relies on some of the same principles, this new-age framework isn’t quite Agile, because it’s past that. It’s what comes after Agile. Even if it doesn’t quite have a name yet, this mindset and attitude are what drives us to build great products. It’s a mentality of fearlessness.
Everyone can challenge themselves in this way, Prolific Ps or not. When you come to a point in the process where you feel the urge to push a task onto someone else or wait for someone to help you out, press yourself to learn how to do the task on your own. Stretch what you normally consider to be the realm of your capabilities and go further. You’ll find that you can accomplish more than you originally thought you could, and you’ll prepare yourself to overcome similar blockers that may arise again down the road. The faster we remove blockers, the faster we get user feedback and the faster we improve the product. And along the way, each individual improves too, making for a stronger and more versatile team in the end.