Requirements Workshops

A Requirements workshop is one of the fastest ways to build consensus, deliberate choices, and make decisions as to the correct path for a project.  If you need to determine what the requirements are for a complex project, gathering everyone in a room and sussing it out can be a very effective way of painting the outlines of an epic.  The downside?  They can be very expensive - tying up that many people at once isn’t exactly cheap!

So how do you run a successful requirements workshop?

Get the right people

Focus on stakeholders that have clout or are SMEs. The attendees HAVE to be able to make decisions about the project. Including the PMO rep from the project is also a good idea so they can get an idea of the project’s scope and can help call out any issues regarding sizing or resources.

Keep the group reasonably small

Don’t invite the whole world.  Only invite stakeholders that are germaine to getting to the “meat” of the issue.  This isn’t a town hall forum.  The more condensed the group, the more effective you can be - with too many attendees it becomes more and more unlikely that you’ll make progress.

Encourage open exchange of information, but keep the group moving

Oftentimes attendees will want to diverge from the subject and talk about their pet topics.  Keep the team focused on the goal at hand - it’s easy for a group to be distracted.

Have an agenda

Because the workshop will have a number of people, it’s very helpful to a clear idea of what you need to determine.  Try to have an outline of the project already completed.  Understand the players involved in the project and what their goals are.  The more you know about the project before stepping into the workshop, the better you’ll be able to guide the group.

Communicate the agenda ahead of time

Since you’ll be leading the group, plan your questions and your agenda ahead of time.  Do not walk into a meeting with a dozen people without your agenda planned out.  

 

Lastly, keep in mind that a requirements workshop ISN’T an implementation workshop.  Hold off on the solutioning until you’ve got all of the requirements outlined.

Noah Weiss and 74 links

Continuing education is one of the keystones of a product manager - if we don't keep refining and improving our skills we are likely to be left behind.  I love Medium and all of the great writing on there - particularly Noah Weiss.  He recently posted an incredible list of 74 Product Management resources.  Covering everything from basic skills to advanced theory it's great reading for all of us.

Prioritization

Every product manager has opinions about product and roadmap prioritization.  As an industry we run the gamut from subjective to objective decision making.  I've seen product managers who fly completely by the seat of their pants,I've seen PMs who poll everyone on their team, I've seen PMs that let the business dictate what to build, and I've seen PMs who refuse to build any feature they don't have hard evidence necessitating.

So while there are a lot of methodologies out there (the Value vs Complexity matrix being a particular favorite with lots and lots and lots and lots of articles about it) I prefer a prioritization matrix with more than two axes.  For any product you have a number of subjective fields: executive priority for one, customer priority for another, your engineering team's priority for yet another.  These priorities don't have any objective values attached to them.  So instead of guessing or ignoring those priorities, let's assign a weight to them (1-10).  For each feature you can then simply add up the values and see what people really care about.  

A process like this shouldn't replace your judgement as a product manager, but it's a great tool that can help guide you to making the right decision.  Ultimately, by assigning some objectivity to a subjective process you can help reduce planning errors and increase the surety with which you plan your product roadmaps!

Reduce, Reuse, and Recycle your products

Balancing competing customer requests can be a challenge, but it's even more of a challenge when your business uses platform managers in addition to product managers.  At a previous employer I was the lead product manager on a platform that saw over three million users per year. On top of my platform the business had constructed six different product lines targeting different market segments, each with their own product manager.  

When I arrived, one of the chief struggles for the team was balancing the requests from the six different product lines.  Each line wanted slightly different features on different timelines, so the engineers spent all of their time sprinting trying to put together functionality for each and every request.  As a result, virtually no time was spent working on the platform itself and it was crumbling under crushing technical debt.

At one point I had three different product lines asking for APIs, two product lines that were asking for single-sign-on functionality, and a line that had even contracted with an outside firm because they couldn't get what they needed in-house!

That experience taught me a valuable lesson: Reduce, Reuse, and Recycle your technology.

Reducing

Try to see across products and customers to see the commonality amongst the requests. By reducing engineering scope in general, you can give your team more time to build thing the right way. In the above example I did this by looking at the SSO requests.  The two products had timelines for completion over a quarter apart and they wanted to use different SSO providers.  Through negotiation with the product managers, I was able to standardize on one SSO framework, set a completion date equidistant between the two timelines, and greatly reduce the amount of work my teams had to do.

Reusing

Reusing existing product work is a great force multiplier that can help you make huge leaps from a functionality standpoint while conserving your strength. At the employer in this example, I did this by looking at the aforementioned APIs and SSO requests.  I was able to build a “new user” API for one of the product lines that was then reused by two other lines later on.  It was built in a generic enough fashion that they could all make use of it, even though their products were slightly different.

Recycling

When you build something, keep extensibility in mind. When writing specs for an import process, walk the fine line between cutting scope and keeping it loose enough to be re-used for other purposes. Let your engineers know when this might happen. I do this by mentioning it as a nonfunctional specification in the story like "when designing this import process, keep in mind that we may want to reuse it to import team or company assignments in the future, not just user assignments."  You don't have to be precise, but just that sentence can give your engineers enough knowledge so they know how to build your product for maximum benefit.

Feature Utilization

Identifying and tracking what is valuable in your software is one of they key tasks for a product manager.  I see two sides to feature utilization: market and internal.  Obviously, knowing how your product's features compare with your competitors is critical.  But I'm going to talk about the latter of those two: Internal feature analysis.  Essentially: What does your customer use and why?

From https://flic.kr/p/7yXRRH

From https://flic.kr/p/7yXRRH

As a product manager working in a startup, one of my biggest challenges is finding product fit.  Because we don’t have an established customer base and we aren’t simply reproducing a product that is already on the market, determining what features our product should have is a learning process.  As such, it’s important for me to see which features our customers like & use, and which they could do without.

I like to break feature utilization analysis up into two groups: Website Utilization & Application Utilization.  There is SO MUCH to say about website utilization I'm going to save that for another blog post.  Heck, there are books published on Google Analytics alone!   The discussions about heatmaps will simply have to wait for another time.  With that in mind, let's talk about application utilization.  

Tracking Basic Utilization

On the most basic level, anytime a user performs an action in your product you should log it in some way.  Whether it's accessing a report, importing a file, processing an order, etc...  Ideally this should be tracked and correlate back to the data involved.  For example, if someone ships an order from your system, you should process the shipment and then log the event in your feature utilization database.  This gives you the ability to trace a user's actions and activities.

Tracking Advanced Utilization

An added layer on top of basic utilization is the element of possible usages. Instead of just tracking "How many times did they click 'X'?", track "How many times did they click 'X' when they had the chance to do so?" Asking this question will clue you into some interesting data in your application.  In a previous role I had an export function that was never ever used.  It was located under a sub-menu and everyone on the product team thought it was logically placed there.  Unfortunately, when we finally looked at how often our customers expanded that particular sub-menu, we were surprised to see that none of them ever did.  We reorganized the menu a bit and saw feature utilization spike.

    Fig 1. Basic Feature Utilization

    Fig 1. Basic Feature Utilization

Application Utilization

On a basic level, it's helpful to just plot out feature utilization and see what parts of your application your users leverage the most (Fig 1).  When I first roll out a feature, this sort of analysis is useful to measure gross consumption.  However, while this gives you a basic view into user activity, it's lacking and is potentially misleading.  

Segmentation

User segmentation and cohort analysis are powerful tools and help you to delve into your users and their behavior. By getting more granular, you can discover surprising insights into your customers.  In the above example (Fig 1), it looks like Feature D isn't very popular, right?  If you look at Fig 2 though, you'll see that Feature D is used exclusively by one cohort.  If that cohort is of sufficient size, then it could make a great deal of sense to invest in it more.

    Fig 2. Feature Utilization Shown by Cohort

    Fig 2. Feature Utilization Shown by Cohort

The cohorts that work for a product are unique to that product, but here are some you can try: Age of user (group users together that signed up on the same day, week, or month), Type of user (either through an actual "type" or by intuiting their actions to infer a type), Geographic region (particularly interesting if your product has international appeal), or user persona (if you can identify it).  

In my current role I can readily associate user personas with users because of our permissions and role schemas.  As a result, we effectively have at least one version of user segmentation done.  However, even within that model, I find value in doing a second layer of segmentation based around age of user and onboarding experience.  So don't be satisfied with just one round of cohort analysis, try a few and see what works best for your team.

Tracking Journeys

Lastly, please realize that while basic utilization and segmentation are helpful, if you want to really understand your users, you have to look at their journeys and understand intent.  Instead of asking "how many times did users click 'X'", with journeys we ask "How many times did users do Y and Z instead of using X?" and "What else were users doing when they DID click 'X'?"  That's where journeys come in.  

For example, if your application lets a user create new teams and import users, it's important to track each feature (Create a new team, Import the users).  But it's also important to track all of the typical tasks a user goes through to accomplish this journey.  You may find that your users spend a lot of time updating user names after importing them, deleting the users and reimporting them because they left off some field, or some other "odd" behavior. 

Conclusion

When you're evaluating feature utilization, play with the data at various levels: get granular with cohort analysis/segmentation and go macro with journeys.  You never know where the data will lead you until you start digging into it.  Remember, your users and their behaviors can provide a wealth of insight into your product.  Make use of it!