Agile Workflow: Successful Product Development Tips from START
The approach known as Agile workflow allows us to tune our managerial decisions dynamically, so as to fit the ever-changing business needs. Let’s take a look at the core principles and tools that help our team at START in building a successful product development strategy.
7 principles behind successful product development
1. Adapting tools to work processes
Our team’s size helps it stay mobile and keep exploring and testing tools to boost our efficiency. At the same time, we adapt all our internal processes to the ever-changing circumstances and business needs. Big companies like FB and Google may have their own set of ideas and methodology at all levels, but we have our own way of doing things. We don’t adjust our development methods to specific tools; we do the opposite. We adapt tools to the process or look for options that suit us the way they come. For instance, we once realised Jira was not all that convenient for our work roadmaps, so we now use Google Sheets, resorting to Jira just at certain stages. Our team opted for a solution that could be integrated into multiple platforms and could process data using formulas and scripts. The issue here is the fact that Jira is poorly suited for high-level task tracking, like when the company’s senior management wants to see what the team is going to do in the next couple of weeks or months. On top of that, tasks in Jira are often described in a complicated language. Ultimately, our particular use case proved Google Sheets to be more suitable for working with our roadmaps.
2. Saving time at all costs
Our goal is to cut the time spent on support as short as possible. Our experts don’t have to oversee the process as it happens with Scrum; the process can essentially run itself. We are also looking for ways to cut down on work meetings. As of now, we just make daily morning calls to discuss the work done the day before and our next plans. Besides, we use these calls to analyse and solve issues together, should any arise.
3. Separate communication channels
We allocate our internal communication channels according to task importance levels. If a question at hand is an urgent one, we use Telegram; this way, we can answer messages in personal chats as quickly as possible. If an immediate response is not required, then team members write emails that can be replied to within a day. Some prefer to check their inbox before starting work, and others do it at the end of their day, after completing all the urgent tasks.
4. Task distribution
When at the global planning stage, we outline all the tasks to be solved and then assess them by three parameters, with three values ranging from minimum to maximum:
- Potential financial benefit from improving user experience or optimising something;
- Resources needed to solve the task;
- Task importance in terms of external agreements.
This approach gives us the freedom to assign tasks with minimal effort and without involving a large workforce. The result of these calculations helps us set the right priority level for each task and distribute goals. This way, we can see which ones can be solved right away, as different projects require different resources. Once prioritised, tasks are analysed using the data gathered, as the architect and product manager decide how to implement them in a quick and cost-efficient manner. If the project at hand is a big one, the team decides whether to aim for a Minimal Viable Product or conduct an experiment. For each product development task, goals are set up on Google Sheets and then linked to the project in Jira.
We also have product sprints, for which we pick the most crucial tasks to solve. If some team members are busy with other projects, we can skip certain parts and move forward. All projects are ranked by value, implementation time, company policy, and general impact on brand image. Next up, we select the resources to be used for a particular task, listing the teams to be involved in development.
5. Working with simple models
The key part of our philosophy is testing our hypotheses on simple models. Implementing them can be fairly easy and quick, but they’ll still help us know which ideas work and which don’t. We don’t bother with innovations that would only slightly increase conversions in the short term. Such modifications are generally pointless; it only makes sense to put in the work if you can grow your product significantly. Over the previous two years, we have been focusing on business-critical tasks such as integrating TV channels or minimising outflow in the billing system.
6. Gauging performance
When teams want to assess product development efficiency, they use cohort analysis. It’s very complex, but it can be crucial when there’s a significant increase in a certain metric. 10–12% improvements are a very positive thing. We always conduct experiments after adding some feature; this way, we can test not just the hypothesis, but also the new features implemented on its basis.
7. Launching straightforward products that get the job done
We do risk management, which means the team starts a new job with predicting and evaluating events. This way, we can have an advance plan for any scenario. Trying to monitor certain metrics until they start growing would limit our choices. We never make our products more complicated out of pure hypotheses; the only reason to do that is when the new feature would bring guaranteed results. This is when one should remember that adding any feature now will require support later — and, naturally, the more complex the product, the more taxing the support will be.
Companies don’t need complex assumption-based models to create successful products. All the tools have to be adapted to the business commitments and current market situation. As far as workflow management goes, teams just have to settle on a system to distribute tasks with minimal effort, and build an easy-to-follow production process.
#Product, #Productdevelopment, #START
