The post Video: Product Management in Games at King appeared first on MindTheProduct.

My question is what have you used to create and maintain the roadmap, and in your experience are there any good resources like sites or books where I could really learn more?

I’ve done searches and find lots of very high-level visuals, but I’m not sure that that is the correct way or whether it should be more detailed in nature. I’d like to gain a better understanding and learn the most effective way to present and maintain the data.

The prior company I worked for never really paid much attention to it – I did it more for myself – but our roadmap really consisted of a huge bug list and new features that I just managed based on our development schedule. So I mainly used Word and created a table with quarters and listed the main features (and larger bugs) per quarter I wanted to get developed, and called them new releases, and adjusted it along the way based on what didn’t get developed and executive non-rational decision making.

— Chris Garby

I certainly feel your pain!  I have also had roadmaps that are overrun by bugs and feature requests. It took me a long time to figure out what was going wrong, because  - inevitably – the roadmap would slip as it’s impossible to plan to that level of detail on an 18-24 month horizon in a single document.

First up, stop thinking of your roadmap as a Gantt chart.  It’s an easy mistake to make because so many product managers use project management tools or techniques to make their roadmap. My ProdPad co-founder, Simon Cast, wrote about this - Don’t use Project Management Tools for Product Management

Think of your roadmap as a strategic communication document.  Its purpose is to show your team and other stakeholders what your product vision is and what the high-level initiatives will be to get there.  It’s not a device for showing off every last nook and cranny of your development plan, and doesn’t need to include your list of specific bugs or minor features you want to get out the door.

Now, realistically, as a product manager, you probably do have a list of bugs and little items that need to be addressed and moved through development. This is fine, but remember that at that point (when you’re helping the development team move items in and through their Kanban/Sprint/Backlog/whatever), you’re playing the role of a project manager or product owner rather than the product manager.  The roadmap is a product management document and should live separately.

Leave out the dates. You don’t know what the expected delivery dates are for anything that goes beyond a couple weeks – ie the length of a sprint, or however long ahead your team specifically plans out as a distinct project or deliverable – and so you shouldn’t fake it! Putting a date on a roadmap, even if it’s vague like ‘Q3 2013′, will more often than not end up setting expectations you don’t deliver on and cause undue stress and finger-pointing among various stakeholders.  While ideally, as the awesome product manager that you are, you’d like to think that you can put a rough estimate on something and stick to it, your estimates suck (from a great book called Rework I recommend everyone reads!).  You don’t know what bugs are going to creep up and change your plans, and even if you did, by the time you get to ‘Q3 2013′, your product strategy might need to adapt and change based on what’s going on in the market, your users, your competition, etc.

Think of your roadmap as a guide, intended to keep everyone aligned and in the loop, but not as a strict project plan. As Steve Johnson said here: “I’m okay with sharing the roadmap… as long as clients and sales people know that the roadmap is a plan and not a commitment.”

As for other great resources, there’s some really smart people you can follow:

• Steve Johnson’s just published an ebook all about roadmaps.
• Marty Cagan is hugely respected in the industry and always has me nodding along to his articles. Here’s some good stuff by him on roadmaps.
• Martin Eriksson (hat tip for introducing me to the concept of roadmapping without dates) founded ProductTank events for product managers and knows his stuff. He’s written a very useful article on prioritising.
• And finally, there’s MindTheProduct.com, where a bunch of other smart product people write. Here are some posts about roadmapping.

Ask a Product Manager is a new series of articles based on great questions and answers given by product managers.  Got a question of your own?  Ask away: ask@mindtheproduct.com

The post Ask A Product Manager: Effective Product Roadmaps appeared first on MindTheProduct.

The post Video: Product Management in Games at Mediatonic appeared first on MindTheProduct.

The post Video: Product Management in Games at Mind Candy appeared first on MindTheProduct.

Some would advocate using the ‘Lean’ method to arrive at a product market fit.  The basic premise is to seek input from customers early in the process to ensure you are building a product people actually want. This allows you to challenge your assumptions and go see for yourself what the problems are you purport to solve.

While there is a lot of validity to this approach if you have identified a viable market and are merely seeking product-market fit, it may not be the best tool for discovering market opportunity. Lean is a great approach to optimization, but it does not help you determine risks or propensity for success when evaluating a brand new product or market concept.

One of the biggest challenges faced with new product innovation is the lack of heuristic models or best practices for discovering product opportunity. This is partly because the market is dynamic and it is difficult to pin down anything truly actionable before the opportunity has changed. But it is also because no heuristic models (set of best practices) has really been defined.

That is the challenge that led to the creation of the ‘product opportunity evaluation matrix’ or POEM framework.  It is a conceptual framework that accounts for fundamental market dynamics in order to help startup entrepreneurs and product managers to think through the conditions of the market, to determine if an idea is likely to be successful or not.  It can be used to identify strengths and weaknesses for an individual idea or to compare overall strength of several ideas to determine which opportunities are most likely to bring success.  By taking this approach, one can take a more informed approach to determining whether to build a new product in the first place, rather than building it, hoping customers show up, and iterating and ‘pivoting’ repeatedly until they do.

The framework is comprised of five forces that drive market opportunity:

• Customer

• Product

• Timing

• Competition

• Finance

Five generally accepted truths are stated for each of the five forces and the practitioner is asked to grade their product concept (A-F) for each of the five truisms.  An averaged score is then derived for each of the five forces.  By going through this exercise, the practitioner is required to account for all of the significant dynamics that may determine the propensity of a product to succeed in the market.

To illustrate how this is useful, consider the metaphor of how cell phone service providers detect location of a device.  Each cell tower can detect an approximate distance of a cellular device from the tower, but can only determine a radius around the tower. Adding a second toward provides directionality and by the time you add a third, you have the basis by which to triangulate a location with a fair degree of confidence.

It is a similar concept in that opportunities in a dynamic market are always moving and changing, and you need a few points from which to reaffirm where opportunities might currently be.  Doing a reasonable evaluation of externally facing factors such as customer, timing and competition will tell you where opportunities are.  And by looking at internally determined considerations such as what product you are proposing and your financial means to provide this product to the market (at this time in the maturity cycle), will give you a much stronger understanding of where the best opportunities are for you or your company to pursue.

The purpose and application of the POEM framework is similar to other open source conceptual frameworks such as SWOT and The Business Model Canvas.  In the case of SWOT the practitioner loosely define the strengths, weaknesses, opportunities and threats they face in their current market, relative to their competition. This is helpful for strategic planning within an organization. Alexander Osterwalder’s Business Model Canvas, meanwhile, has become a popular tool for defining key elements of a business such as partners customer segments, and applicable channels.  With POEM, the purpose is similar, but its application is to provide structure and guidance to the discovery of new product opportunities in the market.

The POEM Framework is a free-to-use open source resource that has been published under the Creative Commons license.  To learn more, please visit POEMFramework.org.  There you will find a detailed explanation of each of the criteria and how to use them. You can also take an interactive quiz for an easy and fun way to try applying the framework for the first time.

The post A Framework For Evaluating Market Opportunity appeared first on MindTheProduct.

Player 1 was Martyn Jones (@ElvisBacon), product manager and game designer at Mind Candy, who spoke to us about validation and iteration during product discovery.  Using the ‘double diamond‘ design process as his guiding theme, Martyn entertained us with his unique combination of hand-crafted slides and visual puns to draw out a few great insights:

• Finding fun is an adventure
• You can’t have deadlines for your product without knowing what to build first
• During discovery, you need to explore loads of ideas to spread your bets as you never know where you’ll find fun – then you can start setting deadlines
• To find fun you need to iterate rapidly and achieve mastery, Yoda-style
• Be honest with your ideas – after iteration, if they’re still not working, park them
• If you’re not the target user (in this case, a kid), you’ll need to remind yourself how they think
• The best friend of a games product manager is a designer – they can help you realise your ideas

Next, we levelled up with Paul Croft (@Bouncinglemon), production director at Mediatonic, who showed us how a data-driven approach complements the quest for fun, particularly in the world of gaming-as-a-service (GaaS).  Some of his observations:

• When starting out on a creative cycle, a blank sheet of paper can be intimidating; constraints – or perhaps context and objectives for the game – are empowering
• “I don’t know the key to success, but the key to failure is trying to please everyone” – Bill Cosby
• The differences in gaming devices, their usage and user demographics have a massive bearing on the design of the products and their ARPU (average return per user)
• Market and competitive analysis in the gaming industry is not just about now, but about predicting how the market will change
• As with Martyn earlier, you don’t know a game will be fun until you try it – so user test your ideas and gather lots of relevant metrics to fine-tune the product
• Pairing creativity with great product management is key to building a successful creative product

Just as we were thinking we’d lost all our lives, Catharina Lavers Mallet (@catharinamallet), head of studio at King turned up with a big bag of loose change to buy us more credits.  Catharina told us all how product management in games is different – it’s about fun, not necessarily about solving problems.

• A difficult level in a game isn’t a problem to be solved by making the level easier – the frustration is what engages the user!
• One of the challenges is knowing which data to measure to find problems – but retention is a key metric
• They split product management function into technical and commercial roles that work really closely together
• Progression through a development cycle from pre-production to launch is accompanied by a move from design to vision & metrics – in other words from qualitative to quantitative as more data becomes available
• Game failure rate is really high, so they use approaches such as their cross-platform strategy to have lots of small risks instead of one big risk
• The initial user experience in games is so important because the commitment to play is so low to begin with – so do lots of user testing!

As a bonus round, we also had some great questions for our speakers from the audience:

“How do you split time between optimising existing products and building new ones?”

One approach is to use future revenue models to determine whether it’s worth investing further in a game.  But if something does need to be changed, our panel was unanimous that chopping and changing during a sprint should be avoided.

“If you have one enormous hit and a few satellite games, how do you build a company strategy around that?”

Martyn described how Mind Candy is building a brand around Moshi Monsters to create other revenue streams other than the game itself.  At Mediatonic, they tend to have several irons in the fire at any one time, replied Paul, a view shared by Catharina.

“How you balance the art and science of gut-feel versus a data-driven approach in games?”

Catharina volunteered that it’s a hard balance to strike, and different in each case.  Paul suggested that useful metrics are ‘attention’ and ‘retention’, as a few percentage points difference can have a massive impact on the success of a game.

“When recruiting a product manager, how do you find people who are fun?”

“Do lots of interviews to test cultural fit,” was Catharina’s suggestion. “It’s really important to find people who can take their ego out of their judgements and empathise,” advised Martyn.  Not to forget good working knowledge of the gaming industry, game design or simply being an keen and articulate gamer, added Paul.

That wrapped up another lively and well-attended ProductTank – the next one will be at 6.30pm on Wednesday 19th June and is all about mCommerce and eCommerce (Event Details).  Do join us then!

We are indebted to eProfessionals for sponsoring the drinks for the evening.  Get in touch with us if you’re interested in curating a ProductTank, writing for our blog on MindTheProduct, or sponsoring our events.

The post Product Management in Gaming (Recap from ProductTank May 2013) appeared first on MindTheProduct.

At Sky I was fortunate to really learn my trade well as product manager, working as I did with the best of the best across the organisation in finance, supply chain, procurement, strategy, marketing, research, technology and innovation. This gave me the skills to move into the small-to-medium enterprise environment and work autonomously without the huge teams and inevitable support a matrix organisation brings.

As a ‘doer’ for several years before I moved into a leadership role I knew I might struggle to completely let go of the day-to-day product owner tasks to entirely focus on line management and all that brings with it. This includes training, skillset building, KPI setting, championing the team across the organisation, representing the team and their work upwards, as well, of course, as being ultimately responsible for the entire output of the department.

In the end this transition happened organically as, initially I still had to be a product owner, as well as manage the team, as there were not enough product managers to cover the product suite. For me ‘managing’ as well as ‘doing’ worked well in the following ways:

• I was able to lead by example.  Day to day I showed the best practice approach to the task-oriented side of product management, as well as the communication elements of the role, taking them along to some of my internal and supplier meetings so they could see how best to lead the teams and be a product owner.
• I could understand the challenges the team encountered, where the current bottlenecks were and who best to approach first if trying to affect change in the business.
• Working on the overall product strategy alongside the CEO and board I was able to speak with the additional authority ground-level experience brings, rather than regurgitating what my team relayed to me.
• I knew what skillsets and abilities existed across the organisation from first-hand experience and could liaise with  contemporaries who headed up sales, support and technology to ensure future planning was based on realistic expectations.

 “I found current ground level knowledge in an organisation was crucial to the role of a product director”

Of course there are also negatives to this approach, but I truly believe that to ‘do’ and ‘manage’ is the nirvana of a product manager, as you get to continue to develop the skillset you’ve nurtured, whilst also getting to be a part of the management team and if you are really lucky, get to define the overall business strategy, as well as the product strategy.

If you want to ‘have it all’ I recommend you focus on:

Time management

Time management is absolutely crucial to the success of this approach. As well as managing your team’s expectations on how much time you can spend with them on their products, you need to consider your board’s expectations on the evolution of the product strategy, how much time and how often you will be able to present back to them and most importantly your own expectations on how often you will make the time to lift yourself up and out of the day-to-day grind. This is the only way you will get the full perspective you need to ensure your vision for your product suite evolves to plan, while assuring you are an effective leader.

Make sure to organise your day precisely, booking time in your calendar to do your line management admin, as well as your own product documentation and, whatever you do, please don’t be afraid to book ten or 15 minute meetings. I know that sounds unreasonable, but even if your office does not have a stand-up meeting area it’s worth creating one (standing by the printer or the drinks cooler). These are so incredibly effective and simple, you will find that people won’t chat and hang about if they have to stand throughout a meeting.

Lists, lists and more lists

• Write everything down, or even use a software as a service (SaaS) tool to help. I found Atlassian’s tool Jira a great way to log the KPIs and tasks I had assigned to my team. These tools also enable you to keep a track of your teams’ work load and report on their productivity.
• Make daily priority lists. Take five minutes every morning (or at the end of the day before) to list out your ‘to dos’, giving them a priority rating. For example have number ones (must do today) number twos (do if there’s time) and number threes (only consider if everything else is done, or can stay late).
• Be uber-organised in your note taking. Have a different note pad for your one-to-one meetings with your team, so you can refer back to these at each subsequent meeting if needs be, to track improvement. Have a different notepad for board/stakeholder meetings, product by product meetings and where necessary write up your notes, either as meeting minutes, or for your own use and reference.

Being a day-to-day doer meant that I really knew what each of the teams in the organisation were capable of and what challenges existed operationally, as well being immersed in the day to day with clients/customers/end users. I found that this was invaluable as I continued to build a product strategy and roadmap, as well as my team strategy. So if you are able to balance this out and manage your time well, your team as well as your product’s innovation will benefit as a result.

The post Moving From Product Management Into Product Strategy appeared first on MindTheProduct.

The roadmap design in ProdPad was such a radical departure from traditional roadmaps that we had no idea whether it would a) work and b) be accepted by users. If we spent lots of time building out a roadmap that then tanked, it was time and effort we couldn’t replace – a killer in a bootstrapped startup. So we went with the minimally viable feature or MVF approach.

We learnt a lot about the roadmap and this has fed into the recent updates to it – all for half a day’s original development.

Why use the MVF approach?

MVFs are particularly useful for products that have moved out of the MVP or minimally viable product stage. Once you reach that point, people start thinking in terms of fully realised features as they plan. These fully realised features will often take significant amount of resources and time to develop and deliver.

Using the MVF approach means you can test before you devote resources to further developing the feature. It allows you to learn as quickly as possible as cheaply as possible.

But will they even use it?

Even if you have half your users asking for a feature it doesn’t necessarily mean they will actually use the feature. What people say they will do is often radically different from what they actually do.

MVFs are a great way of continuing learning as quickly and cheaply as possible, even in mature products. Once a feature shows traction, then you need to double down on that feature and build it out to nurture that traction and realise the value the feature brings to the product. I’ve seen situations where a company didn’t focus effort on a MVF that had a lot of traction, which meant the company failed to capitalise on that traction to create a more valuable product.

When building a new feature, build as little as possible to prove that the users will actually use it.  Get their feedback on what works and what doesn’t, and put that to good use in building out your feature into a fully-fledged facet of your product.

The post The Minimally Viable Feature Approach appeared first on MindTheProduct.

While some may be interested in taking on that type of project (more security and potentially more money), personally, I’ve always pushed back on the client (ever so gently) and assured that the work can be done in a more flexible way, often without the typical five-day-grind commitment for either of us.

A few things to keep in mind when proposing an alternate work schedule:

1. What is the scope of the project?
As an experienced product manager, you should have a pretty good idea of how much time a project is actually going to take to complete. Think through some important questions when proposing more accurate time requirements. Would you need regular access to developers, designers, user experience or stakeholders? If so, the project might be a bit more time intensive as you have to work within other’s schedules and it might require you to be in the office more often. Will you be required to be in quite a few meetings as well? If so, that will take away from the time you’ll need to finish off specific deliverables.

When proposing a more flexible work week, just ensure that you’ve given yourself enough time to actually do the project well. So, take some time to understand the finer details of the project, and if you feel confident that you can deliver in a more flexible way – by all means – tell the client. They should respect you for your know-how and honesty.

2. Why does the organisation want you five days a week?
Is it just for ‘face-time’, aka Marissa Mayer’s resurrected Yahoo! HR policy, (I can say that because I used to work there ? Or, is the project actually going to take that much time? To answer this question, again, think through the requirements of the project.  If you, as an experienced product person, know there’s no reason to work full time to complete the project, find out more about the culture of the organisation.

Quite often, hiring managers seem to feel safer, more comfortable just knowing you’ll be there every day – but that doesn’t ensure the product will be done better/faster than if it was a few days a week. Remember, you’re the product expert and you should feel comfortable helping the client create a project that really will work for both of you.

Happy employer = happy product manager, meaning everyone wins. However, you may find that the culture really is one that requires you at a desk from 9am-6pm, five days a week. At that point, it’s your call. Personally, I’ve walked away from those contracts before.  If I wanted an inflexible work life, I never would’ve gone freelance!

3. How much time do you want to commit to the project?
This will depend on numerous things – your interest in the project; the amount of time that you have to dedicate; even your personal financial situation. Need more money and looking for a stable gig for a few months? Go for it – don’t fight the force! If you’re super interested in the project and think it’ll be a great experience – jump in!

The point is to remember that you are your own boss. There will be times when you/me/we need to take a project to pay the bills. That’s completely understandable. There will also be other times when you can politely tell them to take their five days and …well, you know…:)

The post Tips for managing time expectations in consulting appeared first on MindTheProduct.

Fear when using a product is always there, manifesting itself in different ways. On Twitter it could be the fear of posting something private to your public timeline. For a CRM, it could be the fear of deleting an important contact. It happens to everyone and on every product. I remember when I was first using VisualWebsiteOptimizer I set up a test that used the regex on the URLs to control the pages that the experiment was to occur on. However, there was no way for me to test that the regex was correct and I hadn’t inadvertently done something wrong that would break the site. As I couldn’t be sure it was correct I abandoned the experiment and VWO. The benefit from the experiment was outweighed by the downside of getting the regex wrong. I feared running the experiment.

Fear causes users to abandon products or avoid using a product to its full capacity, which makes it a crucial problem for product managers.  It doesn’t matter how slick or how ‘usable’ your site is. If it doesn’t minimise fear, the product won’t get used.

Here lies the fallacy of ‘intuitive’ user experience. The much-vaunted ‘intuitive’ products aren’t actually intuitive. They are ‘intuitive’ not because they have some wonder design, but simply because they have successfully (on purpose or by accident) reduced the fear in the product to the point users are happy to play and experiment. There is still a learning curve, but users can just rise up that curve quickly and safely.

Starting with the concept of minimising the fear in the product from the beginning will help you build an ‘intuitive’ product. Even if you’ve got a mature product you can still progressively work through the product reducing the fear points. Assuming you don’t have infinite resources (what product manager does?), you need to focus on the most important fear points. Fear points are the steps, actions or functions within your product that generate fear in users.

Focus on the fear points of the product that generate the most damaging fear in users. Surprisingly, this is straightforward. Fear is created when the risk of being wrong exceeds the benefit of doing. Review your product for the journeys and functionality where that happens and then consider the importance of each journey to the overall experience of the product asking yourself the question:

‘Does not using this part of the product material reduce the effectiveness of the product to the user?’

If the answer is yes, then you need to fix that and quickly. Otherwise, your product is not worthwhile to users and they will stop using it. If no, then you don’t need to fix right away.

There are multiple strategies for minimising fear in a product and the approach that you take will depend on what your product is . As a starting point you can consider the three major strategies of undo, sandbox and user guides.

Undo everything
Make everything undoable. Allow users to undo the various actions they have done. This provides the comfort of being able to easily fix any mistakes someone makes make simply by pressing undo.

The original version of merging ideas in ProdPad was irrevocable. Once merged two ideas couldn’t be unmerged. So we had a great big warning during the merge process that it was irrevocable. Every time I used it there was always the fear that I’d screw up the merge and so despite being useful I rarely used it. The current version of idea merge is undoable. If necessary a merge can be reversed, so the psychological barrier to using the feature is much lower. I use merge a lot more now than I used to because I know I can always reverse it if needed.

Love sandboxes
Give users a chance to ‘try’ functionality and practice before working on the real data. The opportunity of testing stuff helps users build the confidence in their abilities. They can make mistakes and fix them without fear of screwing anything important up.

Zapier has an interesting approach to this for both users and developers. For developers you create the Zap and test in ‘dev’ mode allowing you to fix all the problems before making it live to general users. For users as you are creating the Zap you can test to see if you’ve set up everything correctly (the correct data is being pulled from x and is translated correctly for y) before making it live. Both approaches help reduce the fear of using Zapier for the two different user personas that Zapier has.

Teach, I need help
Provide users with the ability to learn how to use a product. Don’t rely on them being able to guess how things work. Providing learning aids gives users confidence when using a product. Whether or not they end up making mistakes, this confidence reduces the fear of the consequences of mistakes. Training aids could be videos, help/how to guides such as we’ve written for Prodpad and interactive guides built into the product, such as you can do with Zurb’s jQuery Joyride plugin.

If you use help/how to guides, don’t rely on the FAQ/knowledge base. You aren’t answering a question, you are teaching. The guides need to walk users through each step of a function or journey and use screenshots so users can understand what is going on. I see far too many companies rely on the FAQ/knowledge base services provided by GetSatisfaction and TenderApp. Mailchimp has some great examples of teaching aids.

Fear is damaging to a product’s value to the user. Unfortunately, fear doesn’t manifest itself in an obvious manner. You have to hunt for fear points within a product. Usability testing can help here, but in the end you need to put yourself in the user’s shoes and work through looking for the places where mistakes could have disastrous effects for the user.

No product is intuitive, despite what the gurus say. There are products where the fear is minimised to the point that users happily adopt and learn how to use it through trial and error, safe in the knowledge that anything they do won’t be disastrous. This is the real ‘intuitive’ UX. There is still a learning curve, but the user is supported to rise as quickly as possible up the curve.

The post Fear or the fallacy of intuitive UX appeared first on MindTheProduct.