It’s cool, but it’s not always so. Some projects just don’t click and don’t inspire us to perfect them. That’s where we blame it on the client, on the team members, the fatigue, magnetic storms, solar flares, you name it. But what if I tell you, there is a high probability that projects don’t work out because we do it all wrong? Do we have the right people, the right tools, the right startup, and yet we approach product development from the wrong angle?
The root of the problem is the team’s disinterest in the success of the product and their desire to get the tasks out of the way never to return to them again.
So here’s our say on how we tackle this issue and what we’ve come to so far.
Why product development drags along
For over a decade in the business of web and mobile development, we’ve failed too many times to ignore the issue. Enough is enough. Admitting the problem was our first step to fixing it. Naturally, first thing you think when a project doesn’t go off is it’s the wrong people and they don’t belong on the team. That is definitely a possibility but it’s way too unlikely to be the reason why your team fails.
A typical dead-end workflow
Any product can be and should be segmented into smaller portions of work and assembled at a final stage. It’s completely natural to build a house brick by brick and same applies to software development. However, imagine building it without a common blueprint on the table and without a chance to live in it after. This turns the process into a mechanical string of actions with no attachment to how it will eventually play out. This makes designers and developers wait for a clear-stated task to appear with their named assigned to it and, ship it, and take the next task.
That’s the reason why your weekly meetings are PMs talking to fill the silence, designers feeling completely out of place, and developers struggling against oscitancy.
It’s not because they are being unprofessional, it’s the environment they’ve been put into that leaves no choice for them. Typically, the following logical yet inefficient workflow is to blame:
This flow makes sense if you have to explain it to your grandmother and if a team needs an excuse to opt out of the stage they’re not really excited about. What this process definitely does is allow and even encourage people to stick to their branch, build a fence, and run their own process within it. There is no inherited responsibility other than the PM’s responsibility in the beginning and at the end of the cycle.
Other than that, it’s the process of “I am not my brother’s keeper.” Wrong. You are.
Here’s what this flow might hit you with:
- Wasted time. Which is one of the worst things that may happen to a company and the client if they work based on the time & material basis. A freely roaming designer might create a prototype that will be hard to implement within the bespoken terms and technical circumstances. This might lead to the executives to reconsidering the initial strategy and budget which will eventually compromise the process in general.
- The Pencil & Coder attitude. In an attempt to fix the previous issue a PM might try to put the team within the scope of some sort which means designers will have a superficial understanding of the business goals and turn into “pencils” as we call them, and the developers will automatically follow to copying the layouts in code. The detachment might result in an inability to assemble a harmonious product with an elaborate functionality and user experience.
- Motivation crisis. Contributing to the success of a project while trying something new, polishing skills, and unfolding professional potential is a way to build a great evidence-based career. Without a chance to step over the bounds, there is no personal attachment to the position they are in which turns an employee into a permanent applicant for their dream job.
- Product’s wasted potential. User research is an important part that comes before ideation and strategizing business goals but how many times do startup owners return to it mid-project development? In that case, the design and development teams become the only users of the digital product. On top of their profound knowledge of the product, they have a chance to tweak it but they never do because they’re not granted any access to the project planning. What ends up happening is we eventually return to that after the first post-launch data and analytics start coming in.
All of these give the products no chance to succeed like they could have. Even though your intentions might be righteous and your team might be as talented as it gets, the stars will never align for you if you don’t look up above you and continue grinding your furrow.
How to change up without changing
All it takes to reinvent the process, avoid the disinterest pitfalls and the dead end, is reestablish the workflow, move on from the linear process to the integrated one. The main idea of the integrated approach is keeping everybody involved from the beginning of the project till the very end.
We started introducing ‘expansion teams’ as the core project squads working on it for the entire duration of the development cycle. A typical expansion team would be a product owner, a project manager, design, and development team leads, and marketers/analysts. We no longer cut the development and design early at the ideation stage. Instead, we encourage them to contribute to the project, determine limitations, and provide insights while the product is still being evaluated.
Even though it might seem like the process got more complicated with more people hogging the blanket, in reality, it makes more sense if you look into it.
A conveyor workflow is much more logical on the surface, but way too inefficient in terms of an intangible input.
Here’s how the expansion team method works:
- Group value assessment. You start off with the product evaluation with an intention to find the balance between the features and business goals through intensive user research. The output at this point is the product value statement.
- Wireframe design. Unlike the linear process where design is somewhat independent, we encourage our development teams to join at the early stage and contribute to the wireframe. To secure ourselves from the visual design arguments early on, we design the structure first and make sure everybody is okay with it.
- Validation happens to ensure we stay true to the original product value statement.
- Backend development kicks off from there on as it does not require too much technical involvement in visual design but at the same time, it acts as an underlying anchor to hold the project in place.
- Prototype design is the next stage after the technical validation of the requirements addressed by the wireframe. Prototype design results in a number of visual assets like graphics, animations, interactions, transition states, etc. Frontend development follows this stage sort of putting ‘flesh on the bones’ of the product.
- Deployment sets in after a fair number of tests and pre-launch validation. The expansion team takes the lead again to make sure the final product meets the expectations, goals, and strategies set at the start. The Launch is, of course, a big deal that has to be performed by the full squad and the expansion team supervision.
- Maintenance and analytics help us figure out what has been done right or wrong, which parts of the process require change, which teams performed best, and how successful the overall company performance was on this specific project.
Most design and development teams can inherit this approach and empower all of their team members with the ability to contribute to the project at every step of its development process. This way, we have seriously rattled the problem of linear production disinterest. By encouraging team members to collaborate more while giving them a fair outlook on the results of their decisions and suggestions, we’ve managed to provide more consistent and wholesome experience to our clients.
With that said, you can’t really count on every member of your team to selflessly work on every project coming your way. They will simply burn themselves out. What you can do instead, is create a pleasant and trustworthy environment with responsible people in charge and shared enthusiasm for the success of whatever you produce.