We did our homework – what are the next steps? – Part 4

First: the most important step for a company is to identify the user’s pain points or particular frustration, rather than focussing on the amount of features you think are good for the user to have. Take a moment and rethink those decisions based on all the user feedback you have, either from surveys, polls, monitoring social channels or from other resources.

Second: validate your findings and put those into perspective. What are your targets or business values you’d like to address or reach? Maybe you have even prepared some possible variations for solving the user’s emotional situation and are ready to concentrate on validation through different user test patterns.

This part concentrates on the steps after you have successfully found emotional trigger points of the existing user base and you have defined a user test group. Maybe, you are ready to deliver new beta solutions to those test groups or you are even willing to provide perpetual alterations to your solutions.

Quick link list for all parts:
Mindset “I am the User” – Part 1
Your Product is a Vitamin Or Painkiller? – Part 2
Talking to Users – But How? – Part 3
You are reading this: We did our homework – What Are the Next Steps? – part 4

Now I know the user, but should I consider all feature requests?

In past projects, we used to create an accessible page for a predefined user group, where all requested features were listed and people could create new requests. With an included voting system, they could vote anything up or down, owning one voice per suggested feature. We were honestly surprised that some features were ditched to the very end of the list, which would have been, in our point of view, beneficial. And others would be at the top, which maybe were not too beneficial out of the company’s point of view. Our view was based on company growth and not yet 100% on the user. Honestly, this was a nice learning.
Now, the tough question is right in front of you: How can users and company interests be combined?

The answer is unique to every company.

I’d recommend to consider a higher percentage of user voted features as – remember – you do want to create a habit for the user using your product. Yet truth needs to be told. Sometimes, the users just don’t know what they really want and they tend to declare preferences, which actually do not solve revealed preferences. Basically, what a user says he wants, is not automatically what he reflects in his user behaviour. That’s to say, the user literally does not know how he wants a feature, he definitely knows his pain point but usually the listed user’s feature will not necessarily solve this issue. If in doubt, ask the user about the problem he was hoping to solve by listing this specific function.

As product manager you are also a product innovator. Your job is to figure out what the user wants before she or he even knows of its existence.

Finally, define a minimum voting number for the feature request to be taken into further consideration to start evaluations with the team. Two things are getting addressed: transparency and credibility. Get the users to trust you. Giving the users the feeling to contributing a decisive role in product developments to get “their own” product.

Should I plan product budget on marketing?

Ask yourself what you want to create. Leads or user feedback? The answer highly depends on the current product cycle, including considering the current market position. If the market position is not yet available, focus on user feedback and spend the budget mostly on test iterations and refinements. The more traffic the product has, the more likely are decisions to mostly focus on growth and revenue. There is one crucial point within every product life cycle, where the product manager should raise one particular question: “Do we still know what our users really want and are we still solving an existing problem?” Rethink the budget, you might want to spend a little more for getting real user feedback even with the downside of limiting the next marketing campaign. Stay on track with the focus user group(s). Try to transfer your product to a daily usage per user, try to make it a habit with triggering the internal user behavior as a need to use the product, e.g. because it makes my daily routines just way easier. This will ensure the product’s sustainability more than a high peak of any marketing campaign. Gaining revenue is mostly a short term peak, a self-returning user is a long term investment.

BTW: same applies for features.

Daily work approach.

When I am talking to other product managers, every now and then we come across our personal daily work approach with the different teams and sharing our experiences. One is for sure: there is no best case. Even though a lot of companies have fully adapted to an agile approach, as the benefits are just too obvious, the usage varies slightly. For me personally, I get the best results for all positions and levels within a team as soon as I write clear and well defined user stories everyone can relate to. If the story is well prepared, everything else will turn out naturally as you go along the process. Story prioritization when talking to stakeholder or team (depending strongly on the product team setup), design adjustments and decisions the team needs to consider while developing, as well as all necessary coordination for a smooth process will be discovered straight ahead and before adjustments are getting too difficult to include. Everyone has the chance to edit the story early enough before starting the next step of the scrum process and one benefit I strongly rely on – every level of the team can relate to the story and does not question it when working on it.

Long story short:

I made the best experiences when a user story includes acceptance criterias for validation and test cycles that are well thought through as soon as the story is taken into sprint planning to define the sprint commitment.

Last but not least – The importance of testing.

Testing allows you to ensure you are going to deliver a working as well as valid solution for the user at any given time. Quality assurance is the software’s fingerprint, so treat it accordingly. One possible technique could be (1.) defining the user’s expectations (based on the user flow) as acceptance criteria to the user story, (2.) attaching those defined ACs as necessary part of a successful test cycle and to eventually proof that the written piece of software fulfills the user’s expectation.

For example: You are about to test an order form for the basket. One AC could be to ensure the software shows all information the user will need to place the order (not necessarily within one page, rather whenever the user needs those information). Another one could be to allow the user to insert and save (for the next purchase) all missing information which are necessary for a successful buying process. For example, a newly signed up user has most likely not jet fully filled out the personal profile. Allow the user to complete the profile while placing the first order and allow the user to decide if all data should be saved to the profile, as well

What are your experiences? I’d be very interested to know. Feel free to use the comment section below.