Published by Ferdinand Vogler on June 10, 2019 ·
4 mins read
At ahead we spend a lot of time improving our process of building our product. We follow a Kanban-influenced approach. We ditched Scrum because there were a lot of time-consuming processes involved that didn’t serve us.
I’d like to share a snapshot of how we build our product. You may find this benefitial if the traditional To-Do, Doing and Done seems too limiting for you and you require more detailed stages.
Doing the right things
The following stages Idea and Research & Validate are handled with ProdPad. This is also where all our customer feedback comes together.
Where to product ideas come from?
Gathering feedback from customers (written, verbally)
Reading industry reports
Talking to co-workers that are in contact with customers
Looking at how customers use our product (in-person meetings, usability testings and data)
Coffee machine pitches, “Wouldn’t it be great if…”
Using the product yourself, therefore “scratching your own itch”.
Looking at competitors. Use with caution, every company operates in their unique context.
Two questions have to be answered to be allowed into the idea box.
What problem does this solve?
What value would it provide if it were solved?
The assumed value is also the hypothesis to test. Problems should be backed up by some kind of feedback patterns emerging. Problems are not solution proposals like “I need a bigger navigation button”.
📖 Research & validate
This stage is optional. Sometimes a problem is clearly understood and the “unknowns” about it are limited. In that case, an idea can go to Start development right away.
Each research method is tailored to the idea it should investigate. If the problem and value aren’t backed up by anything, but we think there might be something to this, we go into further research. Some undertakings remain an experiment and you never know how it will perform until it’s live.
Some ways to research and validate
Prototypes tested by customers
Talk to experts
Research data and eyeball potential impact to the product
Doing things right
If an idea has successfully gone through these two filtering stages, we create it as a user story in Azure DevOps.
🚀 Start development
The user story is ready for our development team to invest time into. They’re ordered from top to bottom from highest to lowest priority.
This stage is divided into two parts.
To be able to enter this stage, the team has to agree on the scope of the user story.
After agreeing on the scope, further refinement work can happen asynchronous. Designers verify prototypes, developers test a new technology.
Depending on the insights we gain above, the story gets further splitted into smaller parts than be shipped.
In addition to a clear problem statement and value proposition, the following acceptance criteria about the user story have been answered and agreed upon by the team.
Functionality — what can it do?
Validations — is there some kind of user-inputted data that needs to be handled? What happens with confirmations, errors, warnings etc.
Translations — What areas to we have to translate? What’s the best wording to achieve the task?
Analytics — what do we want to find out with this? How can we prove our assumed value? How do we measure it?
Public website — any pages need an update? E.g. screenshots
Inform customers — how do we introduce this feature to customers. Any “heads-up” needed?
💡 Planned for development
Developers and Designers get together collectively to break a user story down into (technical) tasks. Clarify who will start working on what.
Getting our hands dirty! Firing up the code editors. Pair- or mob-programming works best.
This stage is about getting an outside perspective and assuring quality.
Present to stakeholders. Stakeholders are people that should be updated about new product features. Currently this includes our CEO, sales team and customer success team.
Test if there are obvious usability issues or errors being thrown in our backend. If so, move back to Developing and iterate. Avoid “gold-plating” an idea. What is good enough?
Feedback in the form of additional feature requests or ideas are seen as new Ideas and go through the normal flow.
Shipped to customers, well done.
How do you work?
How did you adapt Kanban to your team? What would you improve in our flow? This is always work(flow) in progress and I’d love to hear your feedback. Shoot me a message and let’s discuss.