Starting a New Project
While a new project is usually an exciting event, there is always some uncertainty regarding what to do next and how to set things in motion. The following content details each step required to get a new project up and running.
Communication Channels
First things first: how to communicate with the team and with the client?
Two primary communication channels have relied on:
- Slack, for live conversation needs,
- Emails, for the less urgent, asynchronous stuff.
There is an entire section dedicated to how the team manages communications at Nimble. Learn more by reading the communication guidelines.
Email Group
The dedicated email group is used for creating various accounts required to support a project (e.g., email routing service, CI/CD service, etc.). Additionally, it is also used to send incoming emails to all team members.
Each email group follows the same pattern: {client-name}@nimblehq.co.
Slack Channels
Check out the Slack communication guidelines on the communication page.
Slack communication guidelines
Shared Slack Channels
If the client is also using Slack, the preferred setup is using Slack’s shared channels. Shared channels have the significant advantage of leaving the users’ management to each party. Nimble can manage their channel members, and the client can manage their own channel members.
Scheduling Rituals
Communication is key to building a successful product. As part of this belief, the team follows two of the four well-known Scrum ceremonies: Sprint Planning and Iteration Review.
The team chooses not to hold a per-project retrospective for efficiency (to reduce the number of meetings) and because it holds a Chapter Retrospective every two weeks.
For the two ceremonies that the team follows, the Product Manager will schedule them both as recurring events when the project starts.
Sprint Planning
Iteration Review
The iteration review meetings occur once per sprint. They should always happen on the same day of the week as it helps to make it a habit.
-
Goals:
- Reviewing the last iteration’s progress
- Demonstrating the implemented features to the client
- Aligning the next priorities with the client
- Duration: 1 hour
- Parties involved: Client, Product Manager
Introduction to Product Tools
As a product-oriented company, the team has a set of tools and workflows that they know work well. While the team is always open to using an existing toolset, should the client have a workflow already set up, they prefer working with its proven “Product Stack”.
Once the product stack has been selected for the new project, the Product Manager needs to introduce all the tools that the team will use to the client.
Project Exploration
The project exploration phase is one of the most, if not the most, crucial stages in the project. The client and the Product Manager will play a ping-pong game, exchanging loads of questions and answers.
The client may have a clear idea in mind for their product. However, there are two main challenges that the team usually faces:
- Extracting information from someone’s mind is hard. Thoughts aren’t always easy to communicate with others. Especially if those thoughts aren’t crystal clear, which is often the case.
- Clients usually have a good idea of how they want to build their product, but they rarely have an accurate picture of how it will work.
The Product Manager’s responsibility is to get an equal, if not better, understanding of the product than the client. The Product Manager must push the client to explore the limits of their product idea. Of course, this is not to be mean, but rather to make sure that the team has the most comprehensive understanding of their product intentions.
There is only one way to achieve those goals: question everything.
The famous phrase “There is no such thing as a stupid question” has never been more true. As a Product Manager, don’t be afraid to ask a question that others might find dumb. It often leads to identifying edge cases and shortcomings in the logic.
This process will require several emails and meetings. It is typical for all projects and it is paramount to do it right. A proper project exploration will lead to a successful implementation and a healthy relationship with the client.
Project Brief
The project brief comes after project exploration. It represents the newfound understanding of the product, its target users, demographics, competitors landscape, and anything that will help either design or develop the product.
A good project brief must be structured and written with clear and correct English. The project brief will end up in many different people’s hands, and they all need to understand it easily.
The brief doesn’t have to be solely structured text, though. It’s recommended to use and abuse diagrams, mockups, links to documentation, etc. Anything that can help visualize the product will make the brief better.
Project Kickoff
After the project exploration has been completed and the project brief has been written up, the project kickoff will officialize the execution work.
The project kickoff is only a formality and a way for everyone involved to have a clear “go ahead.”
The Product Manager should organize the kickoff meeting, and all team members and stakeholders should be invited: designers, developers, and client.
-
Goals:
- Introduce the team to the client
- Summarize the product and the product goals
- Clarify the roles and the expectations of each party
- Signal to the designers and developers that they are starting their full-time assignment on the project
- Duration: 1 hour
- Parties involved: client, designer(s), developers, product manager
UX/UI Design
The UX/UI design phase is where things start to take shape. It is where any new project will start. The development phase can only start after the UX/UI has been done and approved by the client.
While it is not impossible to start development in parallel with the UX/UI design, it often leads to reworking the product codebase as designs tend to change frequently in the early days. It is counter-productive and creates delays from the beginning of the project. Therefore, it is strongly encouraged to start development only when UX/UI is done.
If the timeline dictates an early start of the development, the design process should be at least mid-way through. The development process should always start with the setup chores: project setup, application variants (staging, production), monitoring, CI/CD, etc.
New Project Checklist
**New Project Checklist**
- [ ] Create the group email
- [ ] Create the Slack channels
- [ ] Schedule the recurring sprint planning
- [ ] Schedule the recurring iteration review
- [ ] Introduce the Product Stack to the client
- [ ] Project exploration
- [ ] Write project brief
- [ ] Kickoff meeting