Category Archives: Product Management

Networking and Blogging – Is it worth it?

Have you ever worked on something only to wonder “is this worth the effort?” “Does it matter at all?”  “Does anyone care?”  I know I have – and it relates in part to these blogs.  In 2013, I set a goal that I was going to write 52 blogs – one per week.  If you have ever tried to maintain a blog site, you know that is an ambitious goal.  But I was committed so even when I would have rather been reading a book or walking the dog, I wrote blogs.  And if I am honest, it did give me a sense of accomplishment when I achieved the goal.

Blogs

As I worked on my 52 blogs, most were about three subjects that I am deeply passionate about: (1) Product Management, (2) Agileflat orb and (3) Leadership.  I have  a good amount of practical experience, I have taken awesome training classes and I have devoted time reading and studying on these subjects, so I hope that I have something useful to share.

Agile: Is Rework Bad?

I recently had an enlightening conversation with someone who was just learning about Agile.  She was deeply entrenched in a Waterfall methodology and legacy PMO practices.  She had lots of questions about how Agile works in a Stage-gate approval process and client contract negotiations.  But what captured my attention most was her frustration over rework.  She said, “we recently had a situation where a client came to us with a half-baked idea.  Before we had finalized the requirements, IT went ahead and worked on something.  That led to seven rounds of rework before we finally satisfied the customer.  How would Agile have handled that?”  It is a good question, but the answer is about far more than just a process change.

Image Source: http://nakedpresenting.co.uk/f-is-for-feedback

Image Source: http://nakedpresenting.co.uk/f-is-for-feedback

Re-thinking Rework

The paradigm shift that Agile suggests is that rework isn’t bad.  That is a challenging concept to get your head around.  Let’s look at the woman’s example again and shift the language slightly.  “Our IT department responded to a client and showed them an option based on the available requirements.  Upon seeing the working software, the client was able to refine their request and provide more clarity to IT.  After seven iterations, the client was thrilled.”  Mind-blowing, right?  If we simply pivot our expectations, we might find that we can be more Agile in our approach to solving customer problems.

Agile and Product Mgmt – Year in Review

I committed this year to write 52 blogs and I did it!  There are 16 on my previous employers website and 36 on www.runyanconsulting.com.  As I look back and review and reflect on the posts, here are my favorites.

Product Management Blogs

I am very passionate about Product Management and I think it is sometimes an undervalued skill set.  Where I have a chance, I always try to share the strategic and practical benefits that come from having great product management resources.  This year, I wrote a five part series about how to Launch a Product and recently completed a 3 part series on how to sunset or decommission a product.

Image Source: http://www.greenbiz.com/

Image Source: http://www.greenbiz.com/

 

Agile Blogs

I am equally passionate about Agile because I have seen how it can improve people’s job satisfaction and raise the level of productivity and effectiveness for the whole organization.  This category was harder to choose my favorites, so I came up with four.  First, there was a series on creating an Agile Culture and what it really means for management.  This series generated some controversy, which I love because it means we are talking about important things.  Next, I am surprised that many organizations are not familiar with Fist of Five.  We use the Agile technique all the time and it is a difference maker in driving productive conversations.  Many organizations also  struggle with how to incorporate Agile into the day-to-day business, so I offered three options for incorporating bugs and maintenance into your Agile teams.  Finally, I am a big believer in the sacredness of the Sprint and I believe that organizations that are disciplined enough to honor a sprint commitment will typically be more successful than those who are loosey-goosey with the guidelines.

Other

Finally, I care deeply about leadership and family so some of my blogs were dedicated to those topics.  One that has been particularly fun is documenting our evolution to an Agile Family.  We have learned (and laughed) a lot together.  Also, I spent some time really thinking about Innovation and what drives an innovative spirit in some people but not others.  This particular blog might be my favorite of the year.

I hope you have enjoyed some of these blogs and maybe learned something new.  I know that I have learned with each post and I am grateful to have the opportunity to continue growing and exploring new ideas.  What is in store for 2014?  Who knows for sure, but it is going to be a great year!

 

Sunsetting a Product: Pricing

It may sound odd that you need to consider pricing when sunsetting a product or platform but you do – at least in some form.  This is the final installment in a series on decommissioning or sunsetting a product.  First you must get data to know exactly what the situation is; second, you must craft your communication plan, and finally, you need to consider the financial implications.

Refunds

If you are truly turning a service off, or ‘going dark’, you may have to consider whether refunds will be required for your existing customers.  If your business model is one of pre-payment, then you need to look into contractual obligations, notice periods and financial true-ups.  The potential impact of refunds may even dictate your sunsetting strategy, so you can minimize pay outs.

Let’s consider an example.  The company charges annually for the following year.  For example, on November 1st, you are charged fordollar_sign2 November 1st to October 31st of the following year.  The company will need to research the month with the highest number of renewals and you might base your decommissioning date based on that information to minimize the refunds.  If sunsetting this product is a large and complex effort, you might consider a rolling project where customers are moved off of the product or platform as their services expire contractually.  This approach can take up to a year to complete, but that might be ideal in certain circumstances.

Sunsetting a product: Get Data

As a Product Manager, one of the efforts that we are often asked to consider is the decommissioning or sunsetting of a product or platform.  It is not always a fun task, but it is very important to the business.  This blog series is dedicated to the steps that a strong Product Manager needs to consider when researching this kind of issue.  The first and most important thing to do is to get data.

If ever there was a project that should NOT be executed based on gut feel, this is it.  You need data to make sure you make the most sunsetprudent decision possible.  There is no way to sunset a product without upsetting some aspects of your business, so this is not something that should be taken lightly.  What kind of data do you need?

Customer Analysis:

You need solid data from the financial and CRM systems of the company to answer the following questions:

  1. How many customers are impacted?
  2. How important are those customers?
  3. What other services have they purchased?
  4. What prices are they paying?
  5. What is their lifetime value?

Step 3: Write a scene for success

In our previous blogs, we have outlined two key steps to take before you dive into that new project or idea that you are so excited about.  Those were: Step 1 – Set your Goals and Step 2 – Define your target audience, or personas.  Now it is time for the final step – decide what success looks like and the best way to do that is to write a scene.  I wish I could say this was my idea, but it’s not.  The smart people at Wharton wrote a great article on this concept called Visionary Leadership: Creating Scenes that Change the Future.   The idea is to define success for your project/challenge/opportunity by creating a scene – like in a movie – of what success would look like in the future.  We did this at a company that we are consulting with and it was a great exercise.

Write the Scene

movie-reel

Image Source: http://www.squidoo.com/screenwriting_tips

Our effort was an Agile implementation at a company with lots of legacy software and its fair share of legacy processes and ideas.  We sat down and pretended that we were through the Agile adoption and the core tenets of Agile were alive and well.  Our scene involved speedy response to a changing market condition, reprioritization of work, team execution of a new deliverable, finding out that deliverable was not the correct response, immediately incorporating that feedback, course-correcting and quickly deploying a more suitable solution.  This scene included management and stakeholders playing a supportive role without judgment, finger-pointing or unnecessary meetings.  Sounds like a dream world, right?  This was a great exercise because it forced us to think about all of the attitudes and practices that would need to change to make this scene a reality and that was eye-opening.

Step 2: Define Personas

It is great to have enthusiasm before you start an exciting project.  But before you jump in, it is critical that you pause and take a moment to consider (1) the goals you are trying to achieve, (2) the people you are trying to serve – by defining personas and (3) defining what success looks like – by creating a scene.

What is a persona?

Who

Image Source: http://blog.oxforddictionaries.com/2013/03/who-or-whom-the-great-debate/

This blog is dedicated to personas.  For those not familiar with the term, personas first came to be discussed relative to writing software in 1999 when Alan Cooper released his book, The Inmates are Running the Asylum.  A persona is a fictitious character that represents an end user that product managers and scrum teams can use to inform their decisions about a product or feature and how it will work.

When you get that great idea, it is important to stop and think about who you are targeting.  What matters to them?  What will mean value to that persona – specific features, a low price point, ease of use?  Using a persona to guide what you will build is very important.  But what about using a persona to decide how you will market?  This can be equally useful.

Step 1: Set Goals

When we get a good idea, it is natural to jump right in and start working.  In recent weeks, several people have had so much enthusiasm about their project that they want to dive right in without any real preparation or fully formed vision of what they want.  To address this, here is a three part blog series on steps to take before you start.  This week’s blog is dedicated to Goals – or defining what you want to accomplish.  Part 2 will be defining your target audience and we will discuss personas.  Finally, part 3 will define what success will look like by creating a screenplay.

SMART Goals?

lighted-path1But first things first.  What are your goals for the project?  Now, many will tell you that you have to define SMART goals – goals that are Specific, Measurable, Attainable, Relevant and Time-bound.  I am going to disagree.  While SMART goals are great, I don’t think you need that much structure for every project.  There is a saying attributed to Voltaire which says “Perfection is the enemy of the good.”  I feel like this applies to goals too.  You can spend so much time trying to define metrics that are measurable and time-bound that you delay the project or miss a critical window.

Agile: The Power of the Fist (of Five)

There is a concept in Agile called Fist of Five.  The notion is simple – when you come to a decision point and you need to make sure everyone is on board,  you ‘vote’.  Agile is all about transparency and Fist of Five is one method to reinforce it.

Image Source: http://nicosteyn.wordpress.com/2011/01/12/5-rules/

Image Source: http://nicosteyn.wordpress.com/2011/01/12/5-rules/

We do it like the game “Rock, Paper, Scissors” where everyone shows their vote at the same time.  One – Two – Three – Shoot.  In theory, this is supposed to keep people from being influenced by their neighbor, but honestly, we think it is just more fun.

The voting works as follows:  A team member will propose a direction forward and the team will demonstrate their acceptance by holding up their hand with the number of fingers that corresponds with their level of support.

5 fingers = I am all in.  I completely agree.
4 fingers = I buy into the option and I will support it.
3 fingers = I may have some reservations, but I can support the decision and move forward.
2 fingers = I have reservations and I cannot support this decision without further discussion and clarification.
1 finger = I cannot support this direction.  I disagree.