Scroll to top

How uses monday dev today

By Leading The Product

As LTP draws closer, we want to highlight the amazing support we receive from our sponsors each year and 2024 is no exception. The wisdom, insights and products that our amazing sponsors have produced are second to none and it wouldn’t be fair to withhold some of their learnings, thoughts and tips on how to adopt new product thinking and adapt to disruption in the product industry.

So please, read and enjoy the awesome content that they have shared with us in the lead up to Leading the Product 2024!

Get inspiration, best practices, and implementation tips help your team launch great products faster

There are 2 ways to become masters of monday dev: You can try it out and explore the platform on your own or, you can use this shortcut where we give you all the secrets.

Here, we’ll walk through how our own product and development teams use monday dev to manage the entire product life cycle, start-to-finish.
You’ll get a behind-the-scenes look at how the platform has made life easier and more efficient for product, development, and collaborating teams. We’ll also share best practices and implementation tips, and hopefully leave you inspired to make changes to the way you work.

Ready to jump in?

Life at before monday dev

Initially, the need for something like monday dev was raised by our ‘product builders,’ as we call them. At, product builders are a squad of product managers, developers, designers, analysts, and partners, all working as a united team to build and launch features and products.

monday dev was built to give these builders a better way to manage the product development lifecycle, end-to-end. The goal, even in the beginning, was to create a product that would connect the builders between themselves, and also to the rest of the organisation – including client-facing teams and leadership. They wanted to create a standardised development process while maintaining each team’s agility to gain visibility, collaborate effectively, and execute fast.

Why was there misalignment? was growing – a lot. With such growth came more team members, more customers to support, and more urgency to launch new features and capabilities.

Our growth at a glance:

Today, we have more than 45 scrum teams working on different domains within the product suite. Each scrum team consists of product managers, designers, and developers. Yet, they collaborate and have cross- domain dependencies.

  • Our client-facing organisation includes more than 800 employees from marketing, sales, support, customer success, and enablement who work closely with our clients to keep them updated on new features and Products.
  • We release more than 30 features a month. This requires a great deal of planning and communication to ensure that all stakeholders and teams are aligned and understand what is happening, and when.
  • We have multiple customer segments, each of which use’s suite of multiproducts differently to satisfy their critical business needs. With growth, came real challenges, including:
  • No standardisation: Our product development process was not standardised, and each department and team was working independently using different platforms and tools.
  • Poor internal communication: Our product roadmap prioritisation was not aligned with the priorities of customer-facing teams. On top of that, the product’s growth wasn’t communicated properly to customers, preventing them from taking advantage of beneficial features and capabilities.
  • Lack of visibility and transparency: Leadership teams and customer- facing teams didn’t have visibility into the product roadmap, project statuses, and release timelines, causing frustration on all sides.
  • Inefficient execution: Developers, designers and analysts were working in silos and weren’t aligning product and business execution efforts. Delivery was slow and inflexible. Product feedback, bugs, and issues were also poorly collected and tracked.
  • Difficulty scaling: As the product changed and evolved, our teams didn’t have a way to work fast and collaborate across departments.
  • To overcome these challenges, we decided to build a platform that would tackle these obstacles head on.

Enter: monday dev.

Implementing monday dev: How we rolled it out As we all know, change is not easy — especially when you’re trying to implement a new software amongst more than 45 scrum teams and 800+ client facing functions. This was a complex company wide effort, but we did it.

So, how exactly did we do it? we:

Planned a full release plan
• Got leadership buy-in to build momentum
• Focused on internal education
• Initiated a gradual rollout that started small and expanded
• Leveraged pre-built templates and workflows in the product and integrated key stack

6 months later, the entire company uses monday dev to collaborate and launch features and products.

How we use monday dev today

Each one of our teams has their own workspace, allowing them to easily collaborate on projects and tasks within the team, and across different departments.

Here’s our workflow today:

Step 1 Ideation and discovery:

This is where everything begins. The ideation and discovery phase serves as a one-stop shop for the team to collect and refine potential features and improvements based on insights gathered from multiple channels. This enables a comprehensive and inclusive approach to product ideation. This stage also includes:

Aggregating knowledge under one roof: The product managers use the “Feature Ideas’’ and “Feedback” boards as a centralised place for gathering inspiration and ideas from various sources, including user interviews, internal team discussions, and client feedback. The team can then prioritise ideas for future development.

Pro tip: use forms to collect feedback and requests from customers or client-facing teams. Information from forms can be automatically added to the board, helping streamline the workflow.

Prioritising: Once all ideas are gathered, the team then assesses which ones to prioritise for development or set aside for later consideration. They consider factors such as the number of requests for a specific feature, an account’s ARR, community votings, resources required, and more. The scoring happens on the board itself, giving all team members visibility into the decision making process. This also empowers product managers to make decisions faster because they can see all input in one organised view. Once a feature is identified as a priority, with one click it’s then added automatically to the board’s backlog, as well as the roadmap board.

Step 2 Establish the roadmap:

Now it’s time to build out the product roadmap. In this phase, a few things happen, including:

Planning the scope and timeline: In the ‘epics’ board (epics are a large body of work that can be broken down into smaller stories), product managers visualise their plans and manage the roadmap, and decide which epics to pursue in each quarter using the information populated automatically from the feature ideas board.

Communicating the roadmap: For each epic, product managers then add an overview document of the process, what it includes, and the timeline. This standardised document is crucial for sharing relevant information across different teams, including challenges being addressed, success metrics and KPIs, the target audience, key feature details, and more. The document also includes the designer’s vision for the solution’s design.

This board plays a crucial role in facilitating collaboration between the product and client-facing teams. The epics board of each team is automatically synchronised to a company level roadmap where our client-facing team works.

Pro tip: use the Gantt view to visualise the roadmap, inform dependencies between different initiatives, and identify potential cross-domain impact.

Step 3 Launch the development phase

In this phase, it’s time to execute. Here’s what happens: Epics are broken into tasks – Once the roadmap is confirmed, the team breaks the epics into tasks in the ‘sprints board’, which is linked back to the epics board. This allows the teams to view the task status, estimated timeline, actual story points, and monitor the epic’s progress.

Sprint planning – The engineering lead then reviews the overall planned story points for the sprint to ensure a sufficient team capacity to manage the effort. They examine the capacity planning using the person widget to verify that effort is evenly distributed among team members.

Monitoring progress and issues – The sprints dashboard provides valuable insights to inform better decisions for the upcoming sprint. The last widget is a progress tracker by team member, enabling managers to monitor the workload assigned to each team member
and focus on daily meetings.
Additionally, the team utilises the burn- down chart as a tool to assess sprint progress, as it illustrates the remaining work over time and helps identify potential issues early on. By analysing changes over time and interruptions within each sprint, the team can also evaluate the story points allocated to bug fixed.

If an issue or a bug is discovered, using the Github integration, The developers can create a new issue in GitHub, label it as a bug and submit it. This action allows us to track how many tasks are planned and unplanned.

Step 4 Release

In the final step, it’s finally time to release. This includes:

Announcing the release: Once the team finishes development and marks an epic as completed on the epics board, it triggers the creation of the epic in the release board, where all released features are detailed.

This information is essential for client-facing teams, product marketing managers, and others involved in communicating these features to clients. Product marketing managers can easily add messaging and launch briefs to the relevant features. Client-facing teams are automatically notified of released features and can update clients accordingly. To speed things up even more, teams can leverage the Slack integration to receive automated notifications on any feature’s status and updates.

Pro tip: add a column for a feedback form, so it will come handy for people reviewing your release.


After implementing monday dev

Using monday dev today, our product and development teams can now easily plan their roadmap, and aggregate important information like requests, feedback, and competitive intel. They can then translate and prioritise that nput into a roadmap, communicate priorities to the rest of the organisation, and establish tangible action plans to execute fast, iterate and release. The best part is that teams can operate from one platform that connects seamlessly to existing workflows and tools like Github, GitLab, Figma, Slack and more.

With monday dev, our product and development teams can also collaborate effectively with the client-facing departments, all working together to collect feedback, communicate releases to clients, and test new upcoming features. It’s a win-win-win for everyone. Development teams can move quickly, iterate fast, and show value earlier, customer-facing teams have transparency into product timelines, and leadership is aligned on prioritisation and the product’s direction. Today, thanks to monday dev, our product and development teams are planning more efficiently, and delivering great products and features to customers faster than ever before.


Let’s wrap it up!

monday dev was born to make the product development lifecycle easy, efficient and more connected to teams and departments. The platform can eliminate bottlenecks, empower seamless collaboration, and speed up time to launch. The end result? Your customers benefit from innovative products and features that can improve the way they work, think, and engage with the world