Prototype to Product – Best practices – The Agile way

Introduction

Agile based product delivery is the buzz-word that every product organization wants to follow. The key reason being quicker turnaround on time-to-market. This includes feature roll-out, incorporating customer feedback and addressing market competition much faster to be  successful.

I admire how great product teams have clear practices or processes that  are defined to support the “Learn-Deliver” approach when it comes to launching product features. Successful product organizations also go through a continuous learning process as part of their product delivery cycle, apart from investing in tools that help follow the aforementioned practices.

I was part of a journey of being a “Engineering manager” for one of the mid-startup organization.Their first product is about a cloud-based video conferencing service for meetings, by enabling people to connect with each other any time, any place and from any device.

As part of business expansion, the startup started thinking about a second product, interactive video communication to large-scale events and conferences. Founders had a thought to create this product following the Agile development methodology, so that they could solve some of the time-to-market challenges they faced with the first product. I was given the responsibility to build the new product the Agile way.

This article is targeted for product mangers, engineering managers and product development teams in product companies, who would like to deliver the time-to-market features the agile way. I will be sharing some of the best practices, which worked for us to deliver features ahead of competition and win the race.

Product managers and product owners manage requirements

“A key mantra to building a winning product is listening to customer needs and working closely with them. At the same time, product managers are also the engineering team’s key stakeholders, for any product requirements.”

In product organizations, the product managers are responsible for maintaining seamless communication with external (customer) and internal (product development) teams, thus achieving customer and market success. Realistically, this is workable only during the early stages of the product. When companies have set their MVP feature set into production and have team sizes of more than 15 people, it’s a lot of work for a single person to handle.

This brings to light a key challenge that product companies, which follow the Agile way of working, have to deal with. If product managers continue to focus their time externally, then the engineering/development teams are affected. For example, stories aren’t detailed enough, development teams have to wait for requirement clarifications and this lag disturbs the overall  development cycle. Alternately, if the product manager spends more time with the development team, the product might suffer from a loss in alignment with customer and market demands.

The best way to solve this, is by having two different roles – the product managers and the  business analyst. The product manager is external focused and works with the product founders to bring a long term vision and market focus to the product. The business analyst works closely with the engineering team to translate/detail the requirements working with product managers.

Discovery as part of the development cycle to conceptualize new ideas

“Can an idea be showcased? The Product manager or product owner wants a quick proof of concept that can be validated with user feedback before the idea gets conceptualized.”

As part of consulting with startup product organizations, I have seen that they adopt a “just do it” approach that skips over key development processes. Problem with this approach is that only some ideas are captured and pushed to production. Post launch and user feedback, a lot of  features (developed this way) are removed, either because of poorly developed features, missing requirements or lack of use. This is a huge reason for start ups to falter.

In the product world, “Listen to user demands, build features and roll-out to production with quick turnaround time” is the game rule which needs to be followed. The product manager maintains a regular communication with customers to help them use the product and get feedback.

“The product development team need to find a process to support validating product ideas and thus ideas gets added to the roadmap.” The approach which worked for us was introducing the “Ideas and Discovery” phase as part of the development cycle.

From a development team perspective, teams were split to have 2 focus areas, one team focussing on product development and the other working on product ideas. As the name suggests, the product idea team worked on prototypes with:

  • Some developer practices like unit tests, integration tests being skipped for later stages
  • The solution not going through a proper testing cycle
  • Hacks/mocks/stubs to get around system integrations etc
  • May or may not be integrated with CI
  • Code is built in a way that it could be re-usable later, if the idea gets added to the roadmap.
  • The code is never a throw away code and the effort don’t go waste
  • Frequent showcases and re-design/develop based on feedback
  • Temporary demo environments for quick demos to customers
  • Code maintained as part of the mainline with feature toggles

Wireframes gets the lifecycle beyond development phase

“Product managers get a lot of ideas from customer feedback, whiteboarding sessions etc. As the product manager gets minimal time to spend with the engineering team,  it’s always a challenge to communicate with engineering teams or product owners.”

With most products or projects, during the requirements phase, wireframes play a vital role in conveying requirements to the development team. The key goal is to eliminate confusion or miscommunication by providing details like user workflow navigation, multiple ways of interaction on specific pages etc.  The process for a wireframe design includes,

During the design phase of the wireframes, product managers play a major role in reviewing and providing feedback on the designs. It’s a iterative process and goes through multiple reviews, to match wireframes with the thought process.

For design, teams uses tools like balsamiq, invision to collaborate and also have regular white-boarding sessions, either co-located or remotely. This approach also helps the engineering team get a holistic view of dependency systems and thus work on technical solutioning. Additionally, it also aids in building the dependency tree with external and internal dependencies.

In addition, what I have experienced is, for product organizations, wireframes can be used in other phases of the product life cycle.

For sales and marketing folks, it helps in branding and adding these features as differentiators in their marketing pitch. By understanding the workflow, they will be able to sell better.

For Customer demos, support and user instructions, these wireframes help in providing the right navigation, user interactions, different entry points to systems etc. This way, strictly following wireframes as part of the development process has helped the internal teams serve the content they were looking for.

Cross skilled and specialist people being part of a single team

“We have more number of specialized people, who have in-depth knowledge, experienced in a specific domain . It’s a very tedious job for them to go across multiple tech stacks and work on system integrations”.

In product organizations, it’s a very common scenario to hire specialized people, who could make a key differentiation for the product. What I have seen is, over a period of time, they form a “tech stack” or “Component” based teams. With this team structure, overall product releases become very cumbersome. They create silos, where no one looks at the bigger picture, releases are blocked because of dependencies and overall, the product suffers a huge backlog.

In a few of my projects, the way we solved this was by forming “Cross functional teams”, which had all the necessary skills to go from concept to production.

But for product organizations, it’s always a given that, you will find that having more number of specialized people and completely cross functional teams have never worked out (in my experience). The way we have solved this is by forming “Feature oriented teams”- for example, recommendations team, on-premise team, Android clients etc.

The way we structured this was like a mini scrum team, which felt more like a startup. They are co-located and self-organized. They have a combination of cross-skilled and specialized people needed to deliver the feature to production. Also each feature team, has their own “Product Owner”, for managing feature set.

For this team to be successful, we definitely need a scrum master, who understands the dependencies, requirements which need special skills and to plan the story flow accordingly. In this structure, both specialists and cross-skill experts have got something to deliver as part of the iteration. This team has all the necessary resources to release and deliver independently. This way, the issue around forming silos and not understanding the bigger picture, is avoided.

One word of caution with feature teams is that we will still need to create strategy around communication, cross feature team interactions, decision making process at product level etc. Also, in this overall feature team structure, we need to have some common functions/people like Product manager, Technical Architect, Dev-Ops and Delivery/Operations lead to work across all feature teams. Some of the following practices have helped us with better communication and top make decisions the product level.

Feature inceptions to manage dependencies

“If dependency management is not done in the right way, it can introduce problems like half integrated features in production, longer feature roll-out cycles etc.”

Every project or product needs to have its own process for managing dependencies. There is no shortcut to this. Also, what I have seen is that there are no common best practices which can work for all.

Coming back to the product world, it has its own additional complexities introduced by various factors like feature support from “Mothership”, prerequisite from other tech layers, integrations between the products etc, which increases its dependency points.This is such a vast topic in itself and product companies have given a lot of thought to this.

The best way to solve dependencies is to find out processes/practices which will help minimize dependencies. Some of the practices, which have helped us includes:

It’s the responsibility of the product manager to maintain a healthy product features backlog. We picked a big wall in our office campus and created a visual representation of the feature backlog/roadmap.This provided us with a clear view of the planned feature set for the product for the next 6 months to 1 year.

One of the approaches we picked up to detail the features to the key stakeholders, was to conduct internal feature inceptions, which run for half a day or so. The inception team included product managers from different platforms, product development leads and other key stakeholders, who impact the roadmap.

At a high level, the outcome of this inception was:

  • Stakeholders, who impact the roadmap are informed about the new features
  • Tech stack and other feature related dependency tree gets created
  • Roll-out dates for the dependencies

As a next step, it is very important to prioritize the feature set. Doing this exercise the correct way helps to minimize time spent on dependency management. For prioritization, some key factors which help us to make decisions include:

  • How critical is the feature from an end-user perspective? What’s the business impact?
  • How long will it take to build this? Do we need to make any team alterations?
  • What is the ROI. Development cost vs. customer impact and the revenue it brings in?
  • What are the dependencies with other systems and their roll out plan?

As we start answering these questions, we created a dependency tree which included both external and internal dependencies and a timeframe for the dependency to be solved. In addition, by following the “Feature team” based structure, we were able to take care of the internal tech stack dependencies. Based on the dependency tree, we could define the product feature roadmap and accordingly communicate to the customer base.

In my experience, if the dependency tree is not well thought through, there are feature roll-out delays  which impact the business.

Conclusion

In my journey with product development, I have learnt that managing product delivery is an art in itself and based on market demands, strategies and processes need to be put in place to manage it.

We also learnt that managing dependencies between product integrations, doesn’t delay the product releases, if these best practices are followed. Introducing these practices and changes to the team structure/roles normally takes around 2-3 months for the team to get introduced to it and start following it.  It’s always a good practice to keep a constant review about the changes and evolve the changes, as it progresses.

Leave a Reply

Your email address will not be published. Required fields are marked *