How to Lead a Project without Releases
More often than not, clients come asking you to develop and publish their apps as soon as possible (my favorite deadline is yesterday). But sometimes the product is ready on time when the client bumps the release date. And then they do it again… and again.
Hi! I’m Mary Yasensky. I’m a project manager at Surf, and I’m here to tell you about how we’d been building one of our favorite projects for half a year. Which was fine, if it wasn’t for the fact that… we hadn’t had a single release in half a year.
The reason was solid, I admit it: the client needed more time to find the people who could provide content for the app. My team, on the other hand, really needed that release.
I’ll share first-hand experience on how to lead a project without releases without losing the motivation, and keeping your spirits up and the client engaged at the same time.
What’s wrong with that? You have no releases — what’s the big deal?
Let’s start by defining what a release is. A release is providing customers with new product capabilities. In our case, technical capabilities, or features.
Any product needs to see the light of day. It has to have updates: you can’t evolve without constant feedback. If the product doesn’t get better, it probably won’t attract new audiences. There’ll be no growth.
But release is vital not only for the users but also for the people who create the product, i.e. the team. Why? Because everyone needs to see the result of their work, realize the value of what they do, and get feedback.
A release is the end result that makes it possible to analyze your work, identify the up- and downsides, and move on to the next stage of improving your product.
The cons of having no releases
Let’s get back to my story. The release was initially planned for November of 2020. My team and I got the app ready by the target release date, but the client bumped the date. That being said, no one planned to stop the project: we kept on adding new features from the backlog.
We kept on coding in peace when, at some point, we faced a problem: our motivation and productivity clearly started dying away. We made awesome things—and put them in the drawer.
In time, even the client stopped noticing any changes in the product: no one used the app, and without releases and clear checkpoints, growth was nowhere to be seen. Meanwhile, the team kept working full time. Here’s what we got as a result:
- Burnout and loss of motivation in the team.
- The client who fails to understand where the money goes because all the updates got muddled together without the logical checkpoints, a.k.a. releases.
How to get rid of cons and get pros
When it started to go downhill, I started thinking about how to fix it. As for the client, it was more or less clear: we needed to show more reports and demos clearly showing what work had been done. The loss of motivation in the team, on the other hand, was harder to tackle. I knew that if I didn’t give my team at least some fake objectives, we could only go so far.
In the end, I arrived at five tools to help keep the team and client interested in the project even without releases.
1. Work in sprints
Even if you already don’t have the objective of meeting deadlines, I recommend breaking the backlog down into sprints:
- Choose a suitable span for your sprint and set the deadline. In our experience, 2–3 weeks is optimal.
- In accordance with the span of your sprint, decompose the tasks and set the scope.
It’s cool if the client takes part in prioritizing the tasks and setting the scope along with the team.
Pros of working in sprints:
- Tasks don’t seem to stretch forever. Every task has its own time limits.
- You can track what features take your team too long to make and cause delays. When you have nowhere to rush, such “procrastination” is pretty likely to happen. Schedules and clear objectives help keep your team alert and alive.
2. Have a demo ready for the client after each sprint
When your project isn’t out in the wild, there are pitfalls waiting for your team: the client might not be thorough enough when checking what you do—after all, the result is not affecting the reputation yet.
My advice is: engage the client in the demo as much as possible: make online calls, share the screen, and show them what’s changed in the product. Don’t ignore even the slightest changes: show not only the big-scale features, but the small fixes in text, bugs, etc. as well.
Such demos need to take place as often as possible: after each print—not when you’re done with all the tasks from the backlog. At the same time, it’ll encourage your team to finish the tasks by the end of each sprint. After all, no one wants to show their client an app with errors in it.
Pros of frequent demos:
- Better transparency for the client.
- You’re sure the client knows what updates have been introduced to the product.
- The team gets an extra milestone to work towards.
3. Peer review
Any product would benefit from user feedback. If your product is not yet published, colleagues might not even know what you’re working so hard on. That’s why they can be a great user audience for app review.
You can agree to showcase the results of your work to your departments. Your colleagues will play the role of users, give you feedback, and help you find the gaps you’ve missed.
When you present the demo in this or that department, you might find it helpful to ask the person working in it to present it. For example, a designer from your team presenting to designers, a tester presenting to testers, etc. It’s always nice to show your achievements to people who know what you’re talking about and are able to appreciate what you’re doing or provide constructive criticism.
Pros:
- You gather opinions from real users without publishing the app.
- You can pinpoint the issues only visible to a fresh eye.
- Again, it’s an extra milestone to work towards.
4. Alpha- and beta- testing
Alpha- and beta- testing is an effective method of trying out an app “in the field” before the actual release. That is particularly important if the app is expecting a huge wave of users in the future . Alpha- and beta-tests will help you carry out load testing of sorts.
App stores check the info about the app and check the app for beta-tests just as thoroughly as they would for the actual release. So, having carried out an alpha-test, you can rest assured that you have all the things necessary for the upcoming release, and that the app itself complies with store requirements.
The client also wins from this kind of testing as it helps do the following:
- Gather feedback and improvement suggestions from real users.
- Hype up the app in the audience.
Experience shows that people like taking part in such tests. And not only the guys from IT, but also the people who want to have an impact on products by their favorite brands. Besides, it’s this audience that becomes the most loyal after the public release: they notice changes and growth in the product better than the others.
Pros:
- The app goes through a real-life check.
- You prepare and check all the things you’ll need for the actual release.
- Feedback from real users.
- The app is more popular when it’s published later on.
- An actual release and joy for your team <3
5. Retrospects and one-to-one meetings
This part is vital—especially when you have no releases and the morale of your team slowly sags.
- It’s better to have retros not less than once a month/ month and a half.
- You might find it useful to have a retro in each department before you have the global one: that way, you’ll analyze all the aspects thoroughly and get the outside points of view. For example, the head of design might provide a designer with unconventional solutions they could implement in the project.
- One-to-ones will help you learn about the mood and struggles in your team that they might not want to share at the retro in front of the entire team.
- You need to give credit to your team and let them know you see how they’ve grown.
Five tools that may help you bolster team morale when they can’t see the results of their work
As we’ve discovered, there are some drawbacks to working on a project and not releasing it: the audience has no idea about the product; the team loses motivation; the client stops noticing the changes. But even if you do your job and put it in the drawer, you can still keep up the morale and successfully grow the project. In such cases, what we need are five tools:
- Sprints: together with the client, break down the features from the backlog and set the deadlines.
- Client demos: at the end of each sprint, showcase all the changes at a personal meeting (online or offline).
- Peer reviews: показываем show your fruits of labor to the colleagues — let them be your users and give you valuable feedback.
- Alpha- and beta-tests: gather all the people willing to take part and carry out the tests. It’s almost like the actual release and everyone’s happy.
- Retrospects and one-to-one meeting with your team: keep track of the atmosphere in your team, get to know their struggles and troubleshoot before it’s too late.
Profit! Down the road—sooner or later—the app will be published after all, and you’ll get to feel sheer happiness because you’ve done a great job.
