This autumn has truly been a season of knowledge sharing. Our team has participated in numerous events and conferences contributing to the development of growing product communities. Recently we attended the Product Development Days event in Krakow, which is known as one of the major product conferences in the CEE. Pavel Pavlovsky and I participated in many activities, and I even had the chance to run a workshop about our approach to managing information overflow. It was an enlightening experience, so in this post I will share what we’ve learned and discuss whether these events are worth attending.

Product Development Days 2018, or as it is more often called, PDD, was focused on increasing innovation and product development skills. Speeches were held in several formats, from traditional presentations to mentoring sessions and workshops. The event gathered experienced speakers from well-known companies like ABB, Amazon, Intel Corporation, Google, McKinsey&Company, Salesforce, and Microsoft as well as innovative and promising startups.

I was pleased to join the awesome team of speakers and contribute to the community of product managers by sharing our approaches during the “How to structure your input so it becomes a manageable scope?” workshop.

Railsware approach to product engineering

At Railsware, we build products for our clients while performing a wide range of functions, from engineering and design to product management. We use the knowledge we’ve acquired over the past 11 years to help them, but also to build our own products that we and others might need. In both cases, we use the same approaches. Efficient idea generation aimed at solving users’ problems is critical for successful product management. We start the project thinking of every next step should be taken and then improve this project based on feedback from several sources. In this regard, most of the product managers face the problem of information overflow.

Collecting and managing inputs

We call all pieces of unorganized or inactionable scope “inputs”. To handle the big stream of incoming information, we gather inputs in a single place, then divide them by context, then optionally add functional labels. This way, we convert unorganized ideas, advice, and feedback into a structured, manageable scope that we can easily work with step-by-step.
To perform this conversion, we take the following actions:

1. Collect. First, we need to gather the incoming information. Usually, it is feedback from three sources:
   • customers
   • product team
   • stakeholders.
2. Put in a single place. We have created a common point of information so that everything comes to the single project in Jira. We call it the “problem space”. Here is what the workflows might look like.
   • Workflow for a product team and stakeholders. We create an issue of the “Input item” type in Jira, indicating the related component (a context), and set a priority – Must, Should, Could, or Won’t, according to the MoSCoW approach. Afterward, it is easy to get the whole picture of the project on a Kanban board.
   • Workflow for customers. For the customer support, we use the Drift widget integrated with Slack, so that a dedicated channel is created for each conversation, and our customer support can answer right away from Slack and then create an input item by dropping the conversation in the Jira ticket description.
3. Groom. If you just put all the incoming information in one place, it still creates chaos due to the variety of related subjects. There can be tech debt tickets, bug reports, bulk customer feedback, or ideas coming from your teammates. All these inputs should be sorted out and structured. So we divide them into groups which we call “contexts”:
   • Assign all inputs to a single specific context.
     • Split multi-context inputs into many single-context inputs.
     • Optionally add a functional label. Labels help to segregate inputs depending on functions people are able to perform, like frontend or backend engineering.
   • Go through contexts to deduplicate inputs.
   • Go through contexts to merge inputs into epics. Epics describe problem space and potential ideas. Epics may span across contexts, but it’s not advised.

Usually, we divide inputs into as specific contexts as possible while creating them to help the responsible teams easily groom the inputs afterward.

The structure is usually built top-down and bottom-up, not just in a single direction. Also, it might have to be changed while grooming.

Now, we have shaped and structured the problem space. When it’s sorted out, we can analyze it and design the solution space where we decide what exactly we are building. Once completed, we move the tickets to the roadmap, where they get priorities and assignees. Now our ideas are converted into the specific action items.

Highlights and challenges of the Inputs approach

So what are the benefits of the Inputs approach?

1. A single source of information for the entire product team streamlines content discovery making a tech debt more transparent.
   Context segregation and better structure simplify prioritization.
2. Visible conversion of ideas and suggestions brings the feeling of ownership and this way boosts collective contributions.
3. “External memory” lets any member capture a thought, write it down as an input and then get back to it when the right time comes.
4. Optimized information and well-structured product components embrace deep focus and simplify management.

From the other side, nothing is perfect. Have been working within the Input approach for the last three years, we have faced several concerns.

1. Inputs might be effortful to manage in terms of different styles and scope of information included.
   • There might be several formats like issues, ideas, domain knowledge, or just a plain text as well as different level of details. For example, a bug can be reported as an issue like just “Allocation mode doesn’t work” while someone will include a detailed and well-structured description explaining behavior, steps to reproduce, expected and actual results.
   • Bulk inputs have to be divided into cohesive pieces while grooming.
   • People might name the same thing differently. It’s actually worthwhile to note the discrepancies between terms used by users, product team, and stakeholders and unify them if possible.
2. The approach requires the diligence to regularly review and groom new inputs into epics. Without an assigned responsible person it will lead to a `/dev/null` problem of hundreds of unresolved inputs and people will stop believing in the value of input creation.
3. It’s crucial to set prioritization criteria to properly convert inputs into getting the right things done.
   • People tend to set a “must” priority way too often, so this should be taken with a grain of salt.
   • A small fraction of power users might push their agenda. Be wary of putting too much weight on inputs from a small fraction of users, they might not be your perfect customer segment. To manage this, do customer and market research to validate any hypothesis drawn from inputs, and create more inputs for these :)

The Product Development Days insights

One of the things I like most about community events is the opportunity to discuss your ideas and concerns with colleagues. We had lots of opportunities to network and exchange experience with other product-oriented people. I was pleased to learn that other companies also use approaches that are very similar to our Inputs (great minds think alike!).

Nourishing the product-oriented and customer-centric strategies

Customer-centric and product-oriented approaches are becoming prevalent in innovative environments. More and more conversation is happening around this topic. PDD was not an exception, there were lots of talks about concentrating on user’s problems and ways of solving them to deliver real value as well as on the power of communication and collaboration in tech and non-tech teams. “Enhancing Corporate Culture – Human interactions in the world of IT” presentation by Ben Szymanski, Vice President, Technical Leader at Brown Brothers Harriman, was a good example proving our vision, too. Its key message was “You work not with code but with people”, so to succeed, you should work in a team collaborating on various types of tasks, but not sit in your own cave implementing just one concrete piece of solution, since code is just one facet of building products.

“How to create customer centric product?” workshop by Aditya Bhuwania, Senior Product Manager at Alexa Voice Service at Amazon Corporate

This episode supported and validated the mindset and approaches we promote at Railsware, I’ve described them in more detail in my previous article.

Here is what I’ve learned:

1. The most important thing is to build something that provides value, so keep the customer at the center of your discussions, create a lot of value and then think about the revenue.
2. Articulate that value you provide to a customer. Cheap should not be your unique value proposition as that will only work until customer finds a cheaper alternative.
3. Customers want to get the experience and feeling of being valued. That should stay at the center of the thought process, which is especially crucial in times of news spreading instantly through social media.
4. In terms of the approach, product manager should:
   • be a generalist, who brings engineers to the next level, comprehends customer needs and opportunities as well as understands the market from the business perspective
   • communicate to empower team by giving them WHY, so they can make decisions on their own
   • segment the problem/the customers as you can’t make everyone happy! It’s also important to understand who should not be your customer. Personas and users’ journeys are good tools for that.
5. How to work with monetization strategies. There are plenty of pricing models that can be applied to a specific product depending on market goals (cost plus pricing, price skimming, penetration pricing, freemium, value based pricing, etc.) and as a product manager, it’s obviously your job to manage it. It’s important to remember that pricing should contribute to the general company goals. Some interesting numbers:
   • 1% increase in price leads to 11% rise in profit margin
   • 1% decrease in cost of goods leads to 6% rise in profit margin
   • 1% increase in operational efficiency leads to 4% rise in profit margin.
6. Measure weekly, considering recurring and one-time revenue and cost. Mix traditional (pre-internet) metrics with innovative ones. Make weekly, monthly, quarterly reports, and of course track trends, as these days everything is progressing so fast!

“How to transition to product management and what does it mean to be a good Product Manager” by Arjun Saksena, Product Manager (formerly Adobe, Evernote, Yahoo) and Co-founder at growth-ai.co

This was another presentation, which resonated with our findings and approaches.

What I’ve learned:

1. There are three types of product manager roles:
   • Enterprise product manager, or technical product manager, possible in big companies (like Cisco) that have a support structure in place.
   • Consumer product manager, who is focused on the customer value and runs all aspects of the product team.
   • Product strategy manager. This is the next level, actually, so you need to prove yourself first as one of the above. A product strategy manager takes care of customers, competition, and investors, and hires and runs a team.
2. To become a (great) product manager you should:
   • be prepared and ask thoughtful questions
   • demonstrate leadership: get things done, deliver
   • move into a fast growing part of the business building relationships with influential project managers
   • follow up on small cues and deliver what people ask for
   • be aligned with the company strategy.

What I especially liked about this presentation, it was that Arjun told his personal growth story: the events of 9/11 grounded him and opened opportunities to grow. He delivered a lot of “how tos”, so it was encouraging and helpful.

“How to grow as product manager i.e which aspects are critical growth areas at different stages of PM growth path” by Syed Masood, Lead Product Manager for Atlassian’s Jira Data Center product

After getting guidelines on how to become a product manager, we also got some great tips on how to develop the most important skills.
What I’ve learned:

1. Leadership and inspiration are the key skills of a product manager.
2. Decision-making is the most important point, so you should analyze problems and make recommendations.
3. Data can be ambiguous! Learn to make conclusions based on 70% knowledge.
4. Customize communication style to suit your audience: find their role and motivators, figure out what problems they face, look for the right arguments to get them to do what you need.
5. Focus on delivering outcomes. Define and track success criteria for the product, otherwise you won’t know where to go and when to stop.
   Delegate effectively by setting proper targets. Make people feel empowered by leaving space to do things however they like as long as they reach goals.
6. Always build relationships with people and don’t let any opportunity pass by.

It was a well-structured presentation which started with the question of how to grow by laying out key skills for the stages of a product management craft mastery along with what a product manager needs to learn at each stage.

“How to make brave decisions to build great products” , by Oana Juncu, Founder, cOemerge.

This topic grabbed my attention because it focused on fears all product managers have, and how to deal with them in a scientific way.
What I’ve learned:

1. Fears block our ability to invent and build successful products, so we should learn how to overcome fear of failure.
2. Cynefin framework is a powerful tool providing several decision-making contexts that help product managers understand how they perceive situations and correct their behavior. Here are some key points:
   • We like predictability as we can deal with fear and danger easily, but great products do not happen here.
   • At a higher threat level of perception we search for patterns, which leads to new cognitive biases.
   • Our brain applies unconscious behaviors to avoid dangerous situations. We should learn how to recognize and change this unconsciousness.
   • In some extra situations, we apply what is called “crisis management”. It requires acting in a very calm way. Good managers first establish the order, then understand where the stability lies, and then it’s possible to respond to the situation.
3. To make brave decisions, we should learn how to transform failures into learning opportunities. This can happen in psychological safety. To achieve it, managers should create an atmosphere of trust so that team members can express ideas without being embarrassed. Encourage the diversity of thoughts, welcome disagreement, cheer creativity!

I believe this information will boost my progress and will help me tell myself “stop” when facing anxiety or even panic.

The significance of a product-market fit

When working on a product, we need to apply the most efficient strategies to select what, when, why and how we are building. In particular, we had a valuable discussion with Pete Sinclair, CEO of Obo Inc., about validating product ideas, optimizing effort, and enhancing collaboration in product teams.

“Product Roadmaps – The fastest route to the wrong destination” by Pete Sinclair, CEO, Obo Inc.

Pete delivered a very insightful presentation focused on the proper methods of idea validation and product plan guidelines.
What I’ve learned:

1. Thorough research. Customer research is not enough, detailed market research is extremely important as well. Customers start using a product for different reasons than why they stay with it. To keep your existing customers happy, you should focus on what they already love about your product. Remember that NPS (net promoter score) doesn’t correlate to revenue, so don’t forget to ask how much people like your product.
2. Features evaluation. When defining your product features, don’t rely on priorities only. Specify a common currency through a set of agreed upon drivers to determine a feature value and align decisions with corporate and product objectives.
3. Build a product plan based on the most valuable features including scenarios and opinions by each department. Don’t forget to trace features from idea to delivery.

Pete’s speech was full of real stories about products that didn’t have a market fit, and also contained a lot of сoncrete recommendations and guidelines. These two features totally match my idea of a perfect presentation!

“The Market Research Conundrum – Why you’re not validating your assumptions – and why you should be” by Pete Sinclair, CEO, Obo Inc.

Pete was also running a workshop, which gave deeper insights in research, ideas validation, and features evaluation. So here are additional tips I’ve gained on this topic:

1. Focus on what users already love and make it better. A unique value proposition for user acquisition is different than for their retention.
2. First do customer research, then market research but remember that data is an indicator, not a driver. Here are some useful tips on market research:
   • Do market research with people you never talk to for understanding why they don’t buy your product.
   • Analyze the market first, then build a product instead of finding the right market for an already built product (uh, it’s a common problem).
   • When you enter the existing market, you need to be ten times better than competitors for users to switch, so focus on capabilities not price, concentrate on painkillers and deliver solutions.
   • You need to predict where your competitors will be in one year. You have to compete against that. Otherwise, you just help them make their roadmaps better.

Tips on customer surveys:

• Test your surveys with the Fibonacci approach (like we do at Railsware :)) before sending them out: test with product managers, sales, customer support people. According to this method, the testing sequence should be 1, 1, 2, 3, 5. So that you test your survey with one person and then apply the feedback you received; afterward you test it with another person and apply their feedback; at the next stage you test it with two people and apply their feedback then, and so on.
• Verify how people understand description of features.
• Reach audience through emails or paid services to recruit a specific audience, such as CEOs :)
• Ask screener questions to refine your audience as soon as possible, as shorter surveys cost less. If an interviewee gets screened out early, you pay only for the questions he has answered, not all of them.
• The more important the issue, the more people you need for statistical significance. 100 respondents will be enough for a discovery, while for insightful, directional, or strategic purposes you need to reach at least 1,000 people.
• Do market research once a month. It might cost as much as your PR.

Market entry strategies

“When, Why and How to Successfully Enter a Market” by Aditya Agashe, Product Manager at Microsoft and Parth Detroja, Product Manager at Facebook

With a related topic, Aditya and Parth inspired me with the great examples of applying the business strategies explained simply using globally known brands as well as some predictions about the future:

• Amazon will acquire Lyft
• Netflix will license music and build their own streaming platform
• Airbnb will partner with Enterprise (a car rental service)
• Apple will make AR glasses.

What else I’ve learned from their speech:

• There are three strategies to enter a market:
  • Build: create a new solution from scratch, which is considered default due to greenfield.
  • Borrow: buy products from third parties, or use something from a different industry for a small amount of money, or make an alliance with another company
  • Buy: acquire an established business. For example, merging Microsoft and LinkedIn increased the LinkedIn’s revenue ten times.

Outline

Nowadays we have numerous sources of information and inspiration like books, blogs, educational videos, and online courses. But for me offline events remain a good opportunity for networking, meeting experienced specialists, exchanging the “live” experience as well as feeling the community vibes. I would say that PDD 2018 gathered around 300 product managers and product owners from those who are just entering the field to the seasoned professionals.

Notwithstanding some schedule overlap, the event did meet my expectations, content-wise it was interesting and engaging. I not only obtained inspiration to try new approaches but also gained practical tips to implement in my everyday work.