Starting a New Project

Hero image for 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?

We rely on two primary communication channels:

  • Slack, for live conversation needs,
  • Emails, for the less urgent, asynchronous stuff.

We have an entire section dedicated to how we manage communications at Nimble, and you can learn more by reading our communication guidelines.

Back to our new project.

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

You can check out our Slack communication guidelines in the communication page.

Slack communication guidelines

All client-specific Slack channels are private.

Shared Slack Channels

If the client is also using Slack, our 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

We believe that communication is key to building a successful product. As part of this belief, we follow two of the four well-known Scrum ceremonies: Sprint Planning and Iteration Review.

We have a company-wide daily stand-up. It is not mentioned in this section because it’s not project-specific and, regardless of assignment, all team members take part in the daily stand-up.

We choose not to hold a per-project retrospective for the sake of efficiency (to reduce the number of meetings) and because we have a Chapter Retrospective every two weeks.

For the two ceremonies that we follow, the Product Manager will schedule them both as recurring events when the project starts.

Sprint Planning

The sprint planning meeting occurs once per sprint. It should always happen on the same day of the week as it helps to make it a habit.

Prerequisite: the iteration backlog should be properly groomed, and the development team should have estimated the user stories before the sprint planning meeting.

  • Goals:
    • Reviewing the upcoming sprint’s content & setting the sprint goal
    • Quickly walking through the features that need to be completed: user flows, backend logic, implementation details (e.g., frontend validation) to ensure that nothing was overlooked during the estimation process.
    • Making sure that all user stories are clear for everyone
    • Addressing any issue or blocker before the sprint starts
      • Should there be any remaining issue (issues must be sorted out before the sprint planning as much as possible), assess whether or not the feature can still be part of the sprint
    • Getting the entire team buy-in to deliver the user stories scheduled in that iteration
  • Duration: 30 minutes to 1 hour
  • Parties involved: Product Manager, development team

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

The sprint planning meeting and the iteration review meeting are often combined into one session only. Going this way will depend on the project and is at the discretion of the Product Manager.

Introduction to Product Tools

As a product-oriented company, we have a set of tools and workflows that we know work well. While we are always open to using an existing toolset, should the client have a workflow already setup, we prefer working with our proven “Product Stack.”

We describe our actual product stack in the “Product Management Tools” section below. Once the product stack has been selected for the new project, the client needs to be informed. The Product Manager needs to introduce all the tools that we will use.

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 we usually face:

  1. 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.
  2. 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 we have 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. You should 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.

Regarding the actual design process, we have a complete design process documentation that you can consult.

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