Based on Ispired book
We have tried to rework and revise our development proccess to make it more Agile\Flexible. Change a sprint planing, rework retros. But nothing helped.
At some point our manager brought us an Ispired book.
We relised that the problem is in global process.
Product development it’s not only coding. It’s not only service realibily, preformance and architecute. It’s user interface, user expiriance, it’s marketing and help center articles.
You could say that it’s not a developer responsibility to do all this types of jobs. And you right.
There is one problem — you have to work together.
What did we do:
Created a product team
We had a development team with services responsibility, Design \ UX Team, Hardware team, Mobile app team, Support team and Project managers to coordinate it.
And we had a person from each responsibility team in our product team.
What does it do:
- we know on what people complain from Support Team
- we know how and why UX was developed from Design team
- we know from PM about the marketing plans
- we know what prodact able to do, and recent updates on firmware from Hardware Team
Use metrics
Now we know whats happaning, from people. But people may guess. Lets guess less. We have to measure. Masure everething we work with.
Do experiments
Lets do it quick. If you want to verify something — do it. During discussian you always tring to geuess. But you are not a user. Your perspective is always different. If you thin it would work — just check it.
You don’t need to develop new service, you don’t need to develop architecture, you don’t need a perfect design. Just try to do it simple and dirty. Just drop a button that would show user a link to a support article or pop-up “under development” . Yes, it’s bad UX. But if noboy click this button at all, it doesn’t make sense to develop this logic. You just can remove it and forget about it.
The positive side of experiments that you never generate legacy logic.
If you your idea worked — develop the concept add more features, logic adn design. If not — you can just remove unused code from experiments.
It corelate with metrics a lot. You have to measue your experiments. You know how often user clicks here. What’s his setup at this moment.
Of course you have to analyse it. Somtimes it’s a lot of work but you are developer — automate it.
We agregated metrics in with DataDog and application logs in ElasticSearch. At some point we realised that we need more than just simple aggregations. We started wtih python scripts and dump CSV exports — to verify that it would work. Later we tried Jupiter Notebook it woked good also. Simple graph and Pandas calculations allowed us to verify simple concepts very quick.
Our designer spent a lot of time to analyse cases, I think we had a luck of automatisation. But we got a lot of spesific feedback from users.
