agile Archives | HatchWorks Your US-based Nearshore software development partner Thu, 30 Nov 2023 15:30:59 +0000 en-US hourly 1 https://wordpress.org/?v=6.4.2 https://hatchworks.com/wp-content/uploads/2021/04/hatchworks-favicon-150x150.png agile Archives | HatchWorks 32 32 A Guide to Creating an Agile Product Roadmap (free templates!) https://hatchworks.com/blog/agile/creating-an-agile-product-roadmap/ Thu, 27 Oct 2022 20:55:28 +0000 https://hatchworks.com/?p=28850 In this hands-on guide, we will show you how to go from a surface-level roadmap that no one looks at (don’t lie, we have all been there) to an Agile product roadmap your team and stakeholders can’t live without. Best of all, this guide will inform your product’s strategy and execution. These are the techniques […]

The post A Guide to Creating an Agile Product Roadmap (free templates!) appeared first on HatchWorks.

]]>

In this hands-on guide, we will show you how to go from a surface-level roadmap that no one looks at (don’t lie, we have all been there) to an Agile product roadmap your team and stakeholders can’t live without. Best of all, this guide will inform your product’s strategy and execution.

These are the techniques we use at HatchWorks to help Agile software development teams deliver products both your users and business will love.

In this in-depth guide, you’ll learn:

 

PS. Don’t miss the free templates throughout the guide!

What is an Agile product roadmap?

An Agile product roadmap is a plan of action for how your solution will evolve over time.

It helps you plan, organize, prioritize, and align your ideas and initiatives across your organization. This way, the most important features and functionality, those that best serve the users of your product, the business, and the technical evolution of your solution, are delivered first.

Your Agile product roadmap acts as a shared source of truth for your team and stakeholders that outlines the vision, direction, priorities, and progress of your product as it evolves.

Think of it like Google Maps guiding you to your destination.

And just like in Google Maps, there is a good chance a better route may be presented after your start your journey, and that is okay!

Your Product Owner is ultimately responsible for the product roadmap, but they by no means define it alone.

Why you need an Agile product roadmap – even as an Agile team

“But we are Agile… We don’t need a roadmap.”

Yes… Yes, you do.

Like death and taxes, change is the one constant in product development. It not only is constant – it is required if you want to build a solution that meets the needs of your users, business, and keeps up with market changes.

At HatchWorks, our approach enables change, hence our motto:

Don’t fear change. Embrace it.”

Change is ever-present… but you still need a plan!

An Agile product roadmap establishes the strategy of your product which provides continuity across the disparate features your teams are working on. It acts as connective tissue for those teams, helping them understand how what they are working on plays into the bigger picture. It also sheds light on dependencies and competing priorities.

While your sprint is sacred, and your sprint backlog should not be changed after the sprint has started, your roadmap is not. It is human nature to want predictability and certainty. But there is a difference between predictability and being a psychic. Not even one of us is the latter, so stop trying to be.

This however doesn’t mean you should go without a plan, especially in a larger organization or for a more mature product where dependencies and complexity are high. At the end of the day, you still have to deliver, and, more importantly, build confidence in your team and stakeholders that you will deliver on-time and on-budget.

The better approach to a rigid roadmap

Align on the level of certainty and depth of your projections and estimates based on how far in the future they are planned. You should be highly certain of your ability to hit items on your roadmap in the current and next few sprints.

  • 3 to 6 months out
    There should be a shared understanding that the prediction of scope and time has a wider certainty range.
  • 6 months to 1 year
    The accuracy range becomes even wider and the depth of detail is more shallow.
  • 1 to 2 years
    Your Agile product roadmap should still be in the strategic conceptual arena having the widest accuracy range. Again for good reason.
    P.S. Don’t feel forced to have a roadmap that predicts further than a year out. It is not always needed.

A roadmap is also a great way to build excitement about where you are going with your team and get buy-in from key stakeholders. It is a rallying cry for the team to achieve something great.

Where to start your Agile product roadmap (spoiler alert: it is not creating the roadmap)

So many people fail at building a roadmap because they start with the roadmap.

Think of a roadmap as the vehicle. You still have to know where you are going and actually drive the car.

You must first start with your product’s strategy, the “why” behind your product.

Without going too deep, the core of strategy is defining 2 specific things:

  1. What market category you will play in?
  2. How you will win in that market category?
 

April Dunford’s positioning framework is a great starting point.

She defines 5 core interrelated areas you must have defined to have a real strategy:

  1. Competitive Alternatives: If you didn’t exist, what would your customers use?
  2. Key Unique Attributes: What features or capabilities do you have that alternatives do not?
  3. Enabling Value: What value do the attributes enable for customers?
  4. Customers That Care: Who cares a lot about the value?
  5. Market You Win: What context makes the value obvious to your target segment?

    Bonus: What seismic shift has happened in the market impacting your ideal customer? Then build a strategic narrative around that.

Now that you have a defined strategy, time to build your roadmap, right?

Wrong.

First, you must validate your strategy so you can test your hypothesis with actual customers or people representative of your target customer. At the end of the day, that is all an untested strategy is – a hypothesis.

Now that you have a sound strategy, the fun part begins.

How to identify, prioritize, and estimate your roadmap items

First, you must identify the key themes and items you want to include on your roadmap. To do this, start with research. Note, this research should be rooted in the strategy (your hypothesis) you defined above. 

Without a defined strategy, it is very easy to go down research rabbit holes, never to be heard from again. 

The 4 main types you need to cover are:

  1. Customer/user research:
    Segment your users, perform qualitative customer interviews, and review quantitative data about how users use your product.
  2. Stakeholder research:
    A great product that doesn’t provide value to the business is not a great product. It is a hobby. Value typically comes in the form of profitable revenue, but not always. Identify your key stakeholders and meet with them. Understand the broader goals of the business, and identify how your product can help achieve those objectives. Understand how your product fits within the broader portfolio of solutions at your company.
  3. Competitive/Market research:
    You have to know what you are up against and what changes are taking place in the market. These changes can either create a huge untapped opportunity or put your product at risk of going the way of the dodo bird. Either way, you need to stay up to speed on both.
    Note on competitive research: Do not do competitive research with the purpose of copying the competition. Instead, look for what the competition is not doing and who they are not serving. Act on those areas of opportunity to stand out in the market.
  4. Solution Architecture Research:
    No product is perfect, all have some form of technical debt. A certain amount of technical debt is maintainable until it is not, it has a funny way of snowballing on you. Be sure to meet with your technical team to identify what technical and architectural priorities exist. That will help enable future functionality for your product. These may not be sexy, but they are what keep the lights on and enable you to keep building.
 

One note on research: Research should never stop. This practice of continuous discovery should be part of your process acting as a consistent feedback loop into your product’s evolution. 

Now that you have done the hard and arguably most important—work, it is time to define the strategic objective you want to accomplish and the key results that will allow you to measure whether or not you are successful. The OKR (Objectives and Key Results) framework is a great approach for this. 

Now, you should be able to identify the key themes and items you want to include on your roadmap that help achieve your OKRs and tie back to your broader product strategy. 

This process is best done collaboratively across your product trio, but let’s assume you have defined the key themes and items you want to include.

Now it is time to prioritize and estimate them.

A great starting point we leverage at HatchWorks is the HatchWorks’ Prioritization Matrix.

This framework is great for facilitating an initial discussion comparing your features value and effort establishing some initial critical buckets of what should be prioritized first. 

Added bonus: It helps you avoid building a Frankenstein’s monster of a product. 

Check out specific details about the framework here.

And here is a Miro template when you are ready to give it a whirl.

A more detailed go-to framework we use at HatchWorks to estimate and prioritize roadmap items is the WSJF (Weighted Shortest Job First) Framework provided by Scaled Agile.

WSJF is great at providing a quantitative relative metric to make prioritization of features objective instead of subjective. Putting items through this framework will help put competing priorities in perspective and give you ammunition to combat the dreaded CEO feature request.

Here’s how it works…

The basic formula is:

WSJF = Cost of Delay / Job Duration (Job size)

Cost Delay is calculated as:

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

Similar to story estimating, the Fibonacci sequence is a great way to relatively measure both the inputs for Cost of Delay and the Job Duration (Job Size).

Start by estimating what you perceive as the smallest item first and then work from there to create an initial baseline.

Once you have this data for all the items in your roadmap, you can simply sort by the highest score and do that first.

Simple.

Here is a WSJF Template to get started prioritizing and estimating your roadmap items.

What to include in your Agile product roadmap

Great! You have all the inputs for your Agile product roadmap. Now what…?

Time to finally build your roadmap!

The first step is to categorize your items into a couple of buckets.

For each item define what category it falls in. A few typical categories are as follows:

  • Feature Category: This is dependent on your type of solution, but some examples could include Billing, Account Management, Reporting, Task Management, etc)
  • Business Driver: ie. Improve user experience, cross-sell, improve security
  • Feature Type: ie. new feature, feature enhancement, reduce technical debt
  • User Persona: define the user persona the feature is serving if applicable
  • Priority: ie. you can use your WSJF score here, or simply start with high, medium, or low but either way there should be a consideration for both value and effort of the feature

Start by doing this in Excel. Here’s a Roadmap Feature Categorization Template to get you started.

Once complete, begin placing items on your product roadmap in a Gantt-style format so you can visualize the timeline of activities. The duration of a feature and how many items you can work on simultaneously will be dependent on the scope of the feature and your team’s velocity.

If you don’t typically release to production every sprint (2 weeks) or shorter, a nice addition is to add planned product release milestones based on when the functionality will be delivered. If taking this approach, it is important to be considerate of the dependencies of the new functionality being released.

Here is a Miro template to build your Gannt-style Agile product roadmap.

Better yet, if you are using Jira, they have built-in functionality that automates the building of your product roadmap.

Pro Tip: If you are struggling to determine how your solution should evolve, try the Product Evolution Canvas.

Note: This is especially effective for new product development and replacement of existing products because as they say, Rome wasn’t built in a day, and your product won’t be either.

In principle, it is the same as a product roadmap, but instead of a Gantt-style view, you instead bucket functionality into 3 specific waves or evolutions of your product to start.

Let’s use an MVP as an example.

A diagram showing a product's evolution from MVP to full-scale product.
  • The intent of an MVP, your first wave, is to be functional. You should be focused on delivering the minimum viable collection of functionality that allows the end user to complete what your solution is intended to do in an end-to-end manner.

    In the example above, the goal is to get from point A to point B, and a fully functioning skateboard does that.

    It may not be pretty, but it should work with the main focus being that the solution actually provides value in a very specific manner. Overloading features in this wave is bad practice. Focus on your core.

  • The second wave is typically focused on the core product. In this phase, you’re getting into more specific core key user scenarios that are of the highest priority for your users.

    Now we are on a bike and have a seat, yay!

  • The third wave is focused on your full-scale product. At this point, you are focused on the core set of features that show off your product’s full potential.
 

Too many folks try to start with the 3rd wave before focusing on accomplishing one high-value, end-to-end user flow in a focused way.

The Product Evolution Canvas helps avoid this trap.

Use our Miro template to align your team on the evolution of your product.

Frequently Asked Questions

The Product Owner is ultimately accountable for the roadmap, but by no means does it alone. It requires input from customers, the strategy, and all areas of the organization. They act as the ultimate synthesizer of that information.

  • Leadership
    Understand your strategy behind the product and understand how it fits in the broader product portfolio and company strategy.
  • Marketing
    Develop the go-to-market plan, educate customers, and generally help create demand and excitement for the new things you are building.
  • Customer Support
    Become aware of new functionality they will need to be skilled in when questions about it come in, and they will. Especially when a big product release is taking place, and they may need more hands on deck.
  • Engineering
    This one is fairly obvious, engineers need to know what to build, but, more importantly, they need to understand the why behind it. Don’t be surprised when your engineers provide you with a better solution for a problem when you give them the why.
  • Sales
    The sales team will need to be aware of new functionality so they can work it into the value they talk about when pitching to customers. They will also want to know if a new product release will impact any of their existing accounts.
In principle they are the same but there are some major differences
Startup Large Company
Duration Shorter: Most startups don’t know if they will be alive in 6 months let alone what they will be building. The focus is generally on the short-term. Longer: Planning is sometimes focused years in the future (not to say they always get it right)
Frequency of Updates Frequent: Startups are focused on shipping, testing, validating, and shipping again. This drives more frequent change to reach product market fit. Infrequent: Large companies tend to have more established user bases and, as a result, have less volatility in their roadmap.
Goals Short-Term Focus: The focus is on validating their business idea and shipping a viable product. Long-Term Focus: Roadmaps are typically more nuanced and have different strategic elements at play.
Dependencies Few: The product and the team are typically smaller allowing teams to be more nimble and step on each other’s toes less. Many: A large company typically has entire teams dedicated to specific functional areas and also tend to have legacy products and integration to consider.

Best practices and mistakes to avoid when building your Agile product roadmap

Best Practices:

It is no surprise story is an effective mechanism (Look at Disney). Use it to your advantage. Your roadmap is essentially a storyboard of where your solution is going and how it is going to help your end users win the day. Use it to get buy-in, rally the troops, and, in general, get folks aligned behind your products why.

The ability to say “No” is a true skill. As a product owner, you have to become skilled in this. Otherwise, you will end up with a product trying to serve everyone but your target customer.

Jira’s roadmapping functionality is a great tool if you’re already managing your product backlog in Jira. Just ensure you are keeping things at the epic level on your roadmap.

Let your team know that your roadmap is a plan and, like any good plan, it is likely to change. Get your team comfortable with change up front, and use it to your advantage to best serve your customer and the market as you continue to learn as you build.

Mistakes to Avoid:

Roadmaps are intended to tell a story about the evolution of your product. Stay at the epic and feature level and don’t get down to user stories. Those are best reserved for your product backlog.

Forecasting and estimating is hard. Be aware of that going in and be careful of always being overly aggressive with your roadmap. If you are always missing your targets, people will begin to take notice, and stop relying on your roadmap

Yes, these are easy, and yes they show you are being productive… But they are an illusion. If you end up building a ton of features no one truly wants, you will end up with a feature rich mess that is extremely hard to sell and has low usage. Go back to your strategy and focus on high value features, even if they are complex and hard to build.

The features on your roadmap are not your kids. Say it again… Sometimes you just have to let certain features go, especially when they end up not tying in with the overall strategy of your product.

Yes, the CEO has a great perspective and is a critical stakeholder when building your product, but you must be careful not to give them a blank check to request anything they want built and have it automatically go to the front of your roadmap. The best way to combat this? A well-structured roadmap. CEOs are logical creatures. Show them why something should not be a high priority with data and logic, and they will typically listen.

This sounds obvious but so many teams fall into this trap. It is the easy way out to just copy what someone else has, but it may not fit into your strategy and plus, someone else is already doing it. That is no way to stand out.

What you communicate to customers and your product roadmap you are executing against are two different things. There is typically higher volititilty in your roadmap which can upset customers if you don’t deliver on time. This is not to say you don’t provide customers an idea of where your product is going, but you should be fairly certain you will be able to deliver and keep it at a much higher level than the one you use internally.

Templates

HatchWorks’ Proven Approach to Iterative Software Development

Building a great Agile product roadmap is not easy, but it is critical if you want to build a product your customers and business will love.

This is a core component of our iterative approach of making sure what we build adapts to the needs of your end-user, your business, and the market.

Need help building and delivering against your product roadmap?

Let us help with our integrated US and Nearshore Agile software development teams.

Getting Started with HatchWorks Is Easy

Contact us to learn about our Agile Consulting solution for distributed Agile Development Teams, and get back to focusing more on your product and less on your process.

The post A Guide to Creating an Agile Product Roadmap (free templates!) appeared first on HatchWorks.

]]> How to Create a Zen-like Agile Software Development Team https://hatchworks.com/blog/software-development/how-to-create-a-zen-like-agile-software-development-team/ Fri, 07 Oct 2022 19:17:22 +0000 https://hatchworks.com/?p=28356 Having a high-performing Agile software development team is like reaching the ultimate state of zen. When you experience it, you just know… The team works with a subconscious intuition, operating as a unit seemingly knowing what each other is thinking, all guided by a common purpose and product vision. But how do you get there? There […]

The post How to Create a Zen-like Agile Software Development Team appeared first on HatchWorks.

]]>

Having a high-performing Agile software development team is like reaching the ultimate state of zen. When you experience it, you just know…

The team works with a subconscious intuition, operating as a unit seemingly knowing what each other is thinking, all guided by a common purpose and product vision.

But how do you get there?

There are core elements you have to get right if you want to create a zen-like, multidisciplinary Agile development team.

In this guide, we cover:

What is an Agile development team?

An Agile development team is a multidisciplinary cross-functional group of 3 to 9 individuals who define, design, build, test, and deliver a working software solution in an incremental Agile fashion. At the end of the day, their goal is to deliver value in each sprint ideally in the form of working code allowing for shorter feedback loops to continually optimize and fine-tune the software solution based on end-user feedback.

Great Agile teams blend creativity and technical expertise marrying the needs of the business, the end user, and the technical feasibility of the solution.

Agile team structure

Let’s start with how your Agile development team should be structured.
(Spoiler alert: there is no perfect structure, but there are standard principles you should follow)

As a baseline, you must have the following roles:

Scrum Master

A scrum master is not a project manager. The role is unique to an Agile team.

A scrum master’s main role is to enable the rest of the team to function more smoothly. They facilitate meetings such as the daily scrum, sprint planning, sprint reviews, etc. They coach the team on Agile best practices and help clear impediments. They should be a servant leader to the team and do what is required for them to be successful.

Frequently, this looks like attending meetings that require team representation, writing status reports and providing other project documentation to those that require it, protecting the team from distractions or disruptions, and providing tools, space, or anything else the team needs to be their best selves (dealing with a tough issue, and a dev runs out of coffee? the scrum master should make the coffee run).

Product Owner

The product owner owns the product and is the single point of contact for the development team. If an answer is needed, the product owner provides it; if a requirement needs clarification, the product owner can do that, too. They should handle communication with the end users of the solution, collecting and prioritizing feedback.

In most teams, the product owner should write stories and help the development team refine them, help triage and prioritize bugs, and manage and maintain the long-term product roadmap. If there is a question on how the system should function or what a business need is, the product owner should understand this. They also work closely with business users, team technical leadership, and designers to make certain that work is being planned and prioritized so the team can deliver as seamlessly as possible.

Development Team

The Scrum Guide groups everyone working on delivery under the umbrella of “developer.” This is nice in theory–everyone is on the same footing–but obscures the fact that certain tasks and skill sets are still required. All developers should be primarily focused on, in a software setting, producing working code. This may include writing the code (devs), testing the code (QA), providing leadership and cross-team coordination (sometimes a software architect or tech lead), and owning and supporting one or more areas of domain expertise.

The developers should, as much as possible, be self-organizing and self-sufficient; if there is a skillset or type of knowledge that is needed consistently on a team, the team should aim to have someone on the team with that skill, and if no one currently does, someone should develop it.

This is where the paint by numbers 101 on how to build an Agile team ends. Other factors now come into play influencing what a proper Agile team looks like for YOUR unique situation.

Here are a few scenarios to keep in mind when building your Agile team:

  • If your solution has a front-end user interface and requires frequent UI changes or new features, you will need a Designer.
  • If your Product Owner needs support writing and refining user stories adding a Business Analyst is a great idea.
  • If your solution requires a large number of infrastructure changes, a dedicated DevOps Engineer will keep things in order.
  • Some organizations prefer an SDET (Software Development Engineer in Test) rather than a traditional Quality Assurance Engineer. SDETs can code and are capable of providing a deeper assessment of issues, and often times are actually able to fix the issue.

At the end of the day, your Agile team structure is less dependent on your organization size and industry, and more dependent on your type of solution, how fast you are expected to deliver, and where your solution is in its lifecycle.

How big should my Agile team be?

A single Agile team can be small or large. In practice, your team size should be no smaller than 3 and no larger than 9 team members, with 7 being the magic sweet spot. Don’t take our word for it. The Agile Alliance also recommends this range.

The popular rule most go by is the two pizza rule. In other words, two pizzas should be enough to satisfy your team (with normal appetites).

The key is identifying the balance between being able to feed your development team enough work relative to being overworked trying to keep them fed. User stories that is… Not pizza. Finding that balance is essential.

Below is a breakdown from smaller team to larger team providing the minimum, ideal, and maximum Agile team makeup.

Small Medium Large
Scrum Master
Scrum Master
Scrum Master
Product Owner
Product Owner
Product Owner
Developer
Business Analyst
Business Analyst
Developer
Developer
Developer
Developer
Developer
Developer
QA
Developer
QA
QA

One caveat: If you team does require a Designer to create a better user experience, and you have a large team, the 9-team member rule still applies. You should look to reduce one of the developers, QA, or BA with the most likely candidate being a developer.

If you have a need for a larger team, you should look to spawn a new team vs going past the 9 team member upper bound.

Want to know how to approach spawning a new Agile development team? Check this out.

How to get your Agile development team started

So where do you get started?

The first thing to consider is this is a team, and like any high-functioning team, it takes time to gel with the ultimate goal of creating an open environment of trust and understanding of each other’s strengths and weaknesses.

A great framework Agile purists follow is Tuckman’s stages of group development.

Phases of Group Development.
The Phases of Group Development are:
1. Forming - Guidance and direction are needed from the manager, purpose and roles are unclear, and efficient processes are not yet established.
2. Storming - Clarity of purpose is established but team relationship dynamics and understanding of how decisions are made are blurry.
3. Norming - As the team organizes around common goals and clear roles and responsibilities, processes begin to optimize.
4. Performing - With a clear vision and purpose, the team delegates and performs well with little oversight.

Once you hit Stage 4: Performing, you are at the Agile state of Zen where every member of the team trusts one another, they understand each other’s strengths and weaknesses, and most importantly they know how to use it to their advantage to build great software that your users will love.

(Don’t be surprised if you start completing each other’s sentences in this stage.)

This leads to one of the most important principles of high-performing Agile development teams.

You should bring work to teams. Not disparate team members to work with.

Once you have a high-functioning team, it is important you keep them intact. Bring them hard problems, and get out of their way.

Otherwise, you are killing one of the greatest bits of equity you have in your organization. The equity realized through a high-performing Agile development team.

6 features of a high performing Agile team

There are a few unique characteristics prototypical high-performing Agile development teams all have. They live by the Agile manifesto, and get the most out of their team.
  1. Multidisciplinary – Each team member brings their own unique skill set and specialized knowledge to the team. Great teams know each other’s strengths and work together toward achieving a common outcome to get the job done.
  2. Self Organizing – A self-organizing team structures and supports itself. People work together best when they determine their own policies, pick their own team leaders, select their own work, and schedule their own meetings. Why? Because autonomy creates empowerment which in turn creates a high-functioning team.
  3. Collaborative – Collaboration is a given, but doing it in a high-functioning way is a whole other ball game. True collaboration across an entire team includes open communication, willingness to cross-train and help upskill each other, being open to each other’s perspectives, and most importantly creating an environment built on trust.
  4. Dedicated – The best Agile scrum teams are dedicated to a single project. Once Agile teams start working across different initiatives and teams, the structure and bond between the team begin to break down as competing priorities and allegiances start to manifest.
  5. Non-hierarchical – Job titles don’t matter on Agile teams. They work best in a flat structure where people are given the autonomy to work independently and organize as needed. In other words, there is no management or reporting structure in a high-functioning Agile team. They work as a group, helping each other accomplish a shared goal.
  6. Outcome-Focused – High-performing Agile development teams are focused on achieving an aligned outcome. Not building features because someone said go build these features. They understand the purpose, business goals, desires, pain points, and opportunities of their business and its users. They know their reason for existing in the organization. This gives them the innate ability to solve hard problems with relative ease.

HatchWorks Agile Consulting for Distributed Agile Teams

Building a high-functioning Agile development team is completely worth the effort.

But it is no small feat to improve your team performance. Especially when you have remote teams.

We have seen teams struggle with:

  • Frequency, size, and stability of their releases
  • Poor visibility into what the team is working on
  • Scope the team is delivering doesn’t match user/customer needs
  • Software development process
  • Experiencing increased team attrition
 

If you are struggling to realize the value of Agile in today’s remote world – HatchWorks can help you:

  • Supercharge your velocity
  • Predict with increased accuracy
  • Ship the right thing faster

Getting Started with HatchWorks Is Easy

Contact us to learn about our Agile Consulting solution for distributed Agile Development Teams, and get back to focusing more on your product and less on your process.

The post How to Create a Zen-like Agile Software Development Team appeared first on HatchWorks.

]]> Finding Focus with guest Matt Paige https://hatchworks.com/podcast/finding-focus-with-guest-matt-paige/ Mon, 15 Aug 2022 22:46:47 +0000 https://hatchworks.com/?p=26645 A self described data driven professional focused on building and scaling engaging products, Matt Paige sits down with Andy Mowat to discuss everything from the importance of deep work time to something he calls “Sunday prep.” https://vimeo.com/739800204 Listen to the podcast Matt is the Vice President of Marketing and Strategy for Hatchworks and has a […]

The post Finding Focus with guest Matt Paige appeared first on HatchWorks.

]]>

A self described data driven professional focused on building and scaling engaging products, Matt Paige sits down with Andy Mowat to discuss everything from the importance of deep work time to something he calls “Sunday prep.”

Listen to the podcast

Matt is the Vice President of Marketing and Strategy for Hatchworks and has a deep background in product strategy and marketing.

The post Finding Focus with guest Matt Paige appeared first on HatchWorks.

]]> The Biggest Mistake Product Managers Make When Prioritizing Their Backlog https://hatchworks.com/blog/product-design/the-biggest-mistake-product-managers-make-when-prioritizing-their-backlog/ Mon, 08 Aug 2022 07:00:10 +0000 https://hatchworks.com/?p=25840 Caution to all you product manager folks out there: BEWARE OF LOW-HANGING FRUIT When it comes to building a product, everyone knows you must make trade-offs, but prioritization is hard. There are competing priorities from: Customers Stakeholders CEO Developers Designers Other product managers And the list goes on… Product managers must ensure they prioritize the […]

The post The Biggest Mistake Product Managers Make When Prioritizing Their Backlog appeared first on HatchWorks.

]]>

Caution to all you product manager folks out there:

BEWARE OF LOW-HANGING FRUIT

When it comes to building a product, everyone knows you must make trade-offs, but prioritization is hard.

There are competing priorities from:

  • Customers
  • Stakeholders
  • CEO
  • Developers
  • Designers
  • Other product managers

And the list goes on…

Product managers must ensure they prioritize the right thing and deliver value to both their customer and the business all while making sure they don’t end up with a product that looks like Frankenstein’s monster.

PS. “feature-rich” isn’t always a good thing. Too much complexity in your product can confuse your ideal customer.

So how do you go about prioritizing the RIGHT THING to build next?

Don’t worry – we have a framework that will make you become a prioritization rockstar and channel your inner Steve Jobs.

Funny enough it deals with apples (no pun intended).

Our Prioritization Framework

Chart to aid with feature prioritization, further described below the caption.

This framework will help you:

  • Visualize your competing priorities
  • Facilitate discussion with stakeholders on what to prioritize
  • Avoid falling into the low-hanging fruit trap

Here is a Miro template to help you with this framework.

Here is how it works:

Simply put Value on the y-axis and Effort on the x-axis.

From there, place your competing features ideas on the matrix based on their effort and value.

(PS. if you want to get fancy, you can color code your features by whether they provide value for your customer or your business. Also, whether they are a net new idea, an existing feature enhancement, or a technology enabler)

This will help you visualize where your competing feature ideas and requests stack up:

Quick Wins (High Value and Low Effort):
Do these first. No matter what.

This is a win-win at its finest. Easy for you AND valuable for your customer (can life get any better??).

Don’t Do (High Effort and Low Value):
As the Whos say to the Grinch, “I wouldn’t touch you with a 39-and-a-half foot pole”

Get these ideas out of your mind and, more importantly, off your product backlog.

It doesn’t matter if your CEO is requesting it. Show them this framework and say, “NO.”

Major Projects (High Value and High Effort):
This is where things get a bit more tricky…

Most folks get overwhelmed by these and shelf them for a sunny day.

The problem is that, many times, this is where those strategic differentiators live. There is no better way to build a moat around your product than to build the hard things that your customers find the most value in.

If it was easy, everyone would do it.

Think hard about these and don’t discount them just because they are difficult. Focus on those features that align with your strategy and truly help you stand out in the mind of your ideal customer.

Trust us. It is worth it.

Beware (Low Effort & Low Value):
These are the fruits that will lull you into complacency and, as a result, leave you with a product that looks more like Frankenstein’s monster and less like something your ideal customer wants to buy.

While these features are easy to deliver and easy to justify, they are also an easy way to fall into the low-hanging fruit trap.

Don’t be that product:

  • The product that tries to serve everyone
  • The product that has so many features, no one has any idea what it actually does
  • The product that is so confusing, that people give up after a day of trying to use it

Be selective.

Be smart.

And don’t be afraid to take on the major project.

Your customers will thank you for it with repeat business and extended contracts, and your business will thank you for it in the bottom line results you are driving.

Do you need a product management guide?

Our product management experts help you build a process for prioritization that will deliver a solution your customers will love backed by product management best practices and proven frameworks.

We work collaboratively with you to bring your product idea to life, understanding your business goals and key metrics to define a solution that delivers value to your business and your customers.

No matter what phase you are at in your software solution journey, HatchWorks can help you accelerate your path to success.

The post The Biggest Mistake Product Managers Make When Prioritizing Their Backlog appeared first on HatchWorks.

]]> What Agile, Recruiting, and Geese Have in Common https://hatchworks.com/blog/agile/what-agile-recruiting-and-geese-have-in-common/ Wed, 18 May 2022 12:00:20 +0000 https://hatchworks.com/?p=24103 Geese – The Creators of Agile Methodology I’ll confess, I’m a nerd. I’m always reading to identify better ways to increase efficiency in recruiting. I stumbled upon an article explaining why geese fly in a V formation and the science behind why their behavioral instinct makes them such a great example of efficiency. First, the […]

The post What Agile, Recruiting, and Geese Have in Common appeared first on HatchWorks.

]]>

Geese – The Creators of Agile Methodology

I’ll confess, I’m a nerd. I’m always reading to identify better ways to increase efficiency in recruiting. I stumbled upon an article explaining why geese fly in a V formation and the science behind why their behavioral instinct makes them such a great example of efficiency.
Geese flying in Agile-like formation.

First, the geese flying formation conserves their energy. Each bird flies slightly above the bird in front of them, resulting in a reduction of wind resistance. The birds alternate being in the front and falling back when they get tired. In this way, the geese can fly long distances before they stop for rest. The authors of a 2001 Nature article state that pelicans who fly alone beat their wings more frequently and have higher heart rates than those that fly in formation. It follows that birds that fly in formation glide more often and reduce energy expenditure (Weimerskirch, 2001).

The second benefit to the V formation is that it is easy to keep track of every bird in the group. Flying in a formation assists with communication and coordination within the group. Fighter pilots use this formation for the same reason. If you have ever watched a group of geese fly overhead, you’ve probably heard them grunting and squawking at each other as they pass. This loud interchange is feedback to ensure each goose is fulfilling their role in the team.

One of the most interesting aspects of geese’ behavior is the intuitive nature of their efficiency. Their ability to fly long distances compared to their counterparts is primarily due to their teamwork efficiency. It’s a complicated process made to look effortless.

What recruiting teams can learn grom geese

If you compare the effortless efficiency of geese to any organization’s recruiting process, you quickly see a stark contrast. The process is usually outdated, laborious, and incredibly inefficient. There are four primary dysfunctions in most recruiting organizations, regardless of industry, size, or the team. They are: 

  • Everything is a Priority, which means NOTHING is a priority
  • It lacks a Rhythm and opportunity for iterative improvement
  • Clients and recruiters are often misaligned on the definition of success
  • The feedback loop is broken

Recruiters are busy and often too stressed to attempt to be productive. Hiring managers wonder why their X number of roles cannot be filled in five days. Candidates are lost in a laborious interview process only to be forced to wait for days on end for feedback about their performance. 

Normal recruiting simply doesn’t work. 

Enter Agile recruiting

At HatchWorks, not only do our software development teams use Agile and Scrum to deliver high-quality products but every facet of the organization embraces the methodology, including recruiting. We use the Sprint Recruiting methodology to ignite, accelerate and succeed in recruiting. It is based on the core principles of Agile and overcomes the dysfunctions of normal recruiting. The four principles are simple:  

  • The SPRINT creates efficiencies
  • The business defines PRIORITY
  • Work in Progress Limits create FOCUS and ITERATIVE EFFICIENCY
  • FEEDBACK keeps the process moving

Recruiters are able to start planning their two-week Agile recruiting sprint focused on the business’s 5-6 top roles versus the twenty or thirty it may have open. The overwhelming distraction associated with high requisition loads subsides as the Agile recruiting team focus on the most critical, manageable requisition list for two weeks. As progress is made on the top priority roles with a specified number of qualified candidates, they move on to the next one in priority. This process is repeated until at some point in the sprint, they create the capacity to recruit other roles as they wait on feedback.

Like the geese flying in a V formation, feedback is constant and keeps the process moving. The feedback from the business moves candidates quickly through the process. Communication among the team helps work be prioritized and allocated to those with the capacity to meet the goal of the two-week sprint. Feedback allows the group to adjust to changes in the industry or client demand quicker and more efficiently. The stress most feel in the traditional recruiting model becomes mitigated by what I call the “sprint instinct.” Like geese, you and your team begin to use resistance as a way to push forward with less energy.

The Hatchworks Agile recruiting team begins the day reviewing a dashboard of ranked jobs with separate swim lanes that show how many candidates are in the process. We meet for daily standups to discuss wins from the previous day and obstacles preventing success. All of our key stakeholders are on the line as we move together as one team toward our ultimate goal: Client Satisfaction. 

Learn more about HatchWorks Sprint Recruiting

Sprint Recruiting was born from the chaos of traditional recruiting. Our process has become more efficient with each iteration, and our engagement with both the business and candidates increased proportionally. Sprint Recruiting guides our journey to iterative growth as we continue to innovate, iterate, and accelerate from Sprint to Sprint.

Talk to HatchWorks today to see how we can help you build the team you need to deliver your next software development project.

The post What Agile, Recruiting, and Geese Have in Common appeared first on HatchWorks.

]]> Leveraging an Agile Approach for Software Development Success https://hatchworks.com/resource/ebook/agile-software-development-methodology/ Wed, 04 Aug 2021 20:09:44 +0000 https://hatchworks.com/?p=22577 In the world of software development, goals can change—and that can be a good thing. In fact, with an Agile iterative development approach that embraces collaboration, any feedback derived through this methodology can drive positive changes that ultimately leads to your success. This guide provides an overview of the benefits of software development that embeds […]

The post Leveraging an Agile Approach for Software Development Success appeared first on HatchWorks.

]]>

In the world of software development, goals can change—and that can be a good thing. 

In fact, with an Agile iterative development approach that embraces collaboration, any feedback derived through this methodology can drive positive changes that ultimately leads to your success.

This guide provides an overview of the benefits of software development that embeds an Agile approach, and how partnering with the right developer can guide you through a process that:

  • Increases predictability
  • Enhances quality
  • Maintains innovation
  • Leads to a host of better outcomes—always

Download This Free Business Guide

The post Leveraging an Agile Approach for Software Development Success appeared first on HatchWorks.

]]> Solving the Enterprise Innovation Challenge https://hatchworks.com/blog/modernization/solving-the-enterprise-innovation-challenge/ Wed, 07 Jul 2021 16:42:45 +0000 https://hatchworks.com/?p=22087 We all know the reality of the enterprise environment. Organizational size can often be a double-edged sword—big enough to apply resources to fuel innovation, yet too big to be nimble enough to jump-start the creative process. In other words, larger enterprises have the resources to innovate, yet far too often they are not able to […]

The post Solving the Enterprise Innovation Challenge appeared first on HatchWorks.

]]>

We all know the reality of the enterprise environment. Organizational size can often be a double-edged sword—big enough to apply resources to fuel innovation, yet too big to be nimble enough to jump-start the creative process. In other words, larger enterprises have the resources to innovate, yet far too often they are not able to execute.

Why is that? For many larger organizations, they first tend to be more firmly rooted in ensuring that all systems stay up-and-running as-is. This is often due to legacy IT systems and architectures that represent current embedded revenue generation—paired with a lack of bandwidth and verticalized expertise, which impedes the ability to expedite new approaches to product development strategies and execution.

So what do enterprises do to address this seemingly ever-looming innovation challenge? Well, the good news is that they can ensure size does not stand in the way of progress—but they will need help. Outside help.

The first step is finding the service provider. Lord knows the world is full of companies claiming to solve enterprise challenges—but many often fall short due to a lack of experience, or simply a lack of knowledge in a particular vertical market. My recommendation here is to seek out and vet a multitude of companies—finding the best fit for your particular situation. And yes, I know that’s a task that is easier said than done.

Perhaps the best way to look at it is through the focused lens of skill-sets, processes, and innovation. Enterprise Software Services come in a multitude of flavors. However, many of those services simply fit into the category of antiquated software development—rarely, if ever, delivering something tangible and successful.

Instead, what the right Enterprise Software Services provider should claim (and subsequently deliver) is the ability to bring you true-to-form, end-to-end, full-lifecycle software product development and support—ensuring the strongest and most positive user experience possible.

So how do you know this will be accomplished by the partner you select? This is where proven processes come in. Put simply, your partner should be able to unequivocally prove their ability to define your business case and market advantage, create a product roadmap built for scale and innovation, and develop a scalable solution. They should also be able to demonstrate their prowess to launch your new and updated applications in the cloud, and then manage them post-launch.

Your partner should have proven Agile development processes, and state-of-the-art infrastructure expertise—enabling them to define, design and develop solutions in a fraction of the time of antiquated approaches. These skills would ideally also include the use of modern languages, frameworks, tools, other software programs and systems to leverage existing components and improve upon existing systems with modern approaches to development.

Moreover, your partner should have the skill-sets and know-how to enable advanced technical architecture and infrastructure to support a better, enhanced user experience—and provide predictable, scalable development cycles for improved accuracy on timeline to delivery.

In the end, the right partner is hard to find. But once you do find them, they will be an integral part of your business growth and success for years to come. Got questions? Reach out to me directly—let’s discuss what you require and how to get there—we’re always here to help.

Getting Started with HatchWorks Is Easy

HatchWorks will work with you to perform a free initial assessment of the team composition you need based on your current team structure. They can work as an autonomous dedicated team or integrate with your own team to meet your needs. No matter what phase you are at in your software solution journey, HatchWorks can help you accelerate your path to success.

The post Solving the Enterprise Innovation Challenge appeared first on HatchWorks.

]]>