Rich Mironov @ SF StartUP Product Talks May 16, 2012

May 17, 2012 in Events, Product Management with 0 Comments

Rich Mironov led the discussion at the most recent SF StartUP ProductTalks. My introduction to product management was Rich’s book The Art of Product Management, so it was great to see him talk!

A huge thanks goes out to Rich for speaking and curating the discussion.

Below are my notes from Rich’s talk and the discussion. It was also interesting to see the folks looking for work and those who had open positions in their companies, although as Rich said – “you’re all looking for unicorns”, as in we are all looking for very particular people for our jobs and not filling roles with the available people when they are more than competent. That was an interesting takeaway for me.

On to the discussion notes:

@richmironov

To get things started Rich asked the attendees for some topics they wanted to learn more about, the results were:

  •  Product Owner vs Product Manager (16 votes)
  • Technical Skillset (15)
  • Working with Developers (8)
  • How to transition from project management to product management? (7)
  • Certifications (2)

What does a product manager do? (Slide deck)

(Slide 2)

Product Managers sit between three groups that don’t talk together, sit together, or have a common language. Executives, Marketing & Sales / Markets & Customers, Development

Development

  • PM Input – business requirements, guidance, market information, priorities, user stories, personas
  • Dev Output – software
  • If you are in development you are often blind to the interactions that PM has with the rest of the organisation.

Marketing/Sales & Market/Customers

  • PM Input: segmentation, pricing, demos; output: feedback
  • sales and marketing communicates what the customers provide

If you poll sales people:

  • why we win sales: awesome salespeople
  • why we lose sales: product sucks, too expensive, not enough collateral

Sales people have a ‘stack depth’ of one – they only remember what the customer asked for in the last meeting.

As PM people we need to talk to customers/prospects directly.

Executives

  • PM Input – market models, strategy, forecasts, etc
  • Exec Output – vision, budgets, staff, targets

The ideal candidate for a Product Management position is someone who has been in each of these roles:

  • They will have been in development or know enough to call BS. However, engineers who move into PM often find this hard as making a more “correct argument” doesn’t float.
  • “If you’ve never ridden in a car with someone who has a quota you don’t know sales”.
  • Executives care about keeping the company afloat.

Three different groups, with different skills and different languages. Hard to find this within one person, so you can try to build a team that does have those skills. Product Management is a hard job for anyone – “smart people go find something else to do eventually”.

Agile Planning Onion - Mike Cohn: Daily, Sprint, Release, Product, Portfolio, Strategy. Product Managers live in the middle – three to twelve month period – and bridge the strategy that Executives have laid down with the limited set of staff the organisation has.

Product Owner vs Product Manager

(Slide 5)

Does it depend on the company?

People from the Agile space – Product Owners – often don’t know how to sell and market products or how to get those products into the market successfully. Further, they often don’t know how to EOL a product or support the product when it is in production. They know how to build products.

Agile people often feel if you make it they will come, why won’t the world buy it. Emergent business model. We don’t know who we will sell this to, we’ll figure it out on the way.

The Product Manager is the wrapper, the overarching strategic folks that listen to customers/support engineers/sales people/developers/executives, and then set a direction, plan and price and market the product.

“Eric Ries brilliant” – taken direct marketing science and introduced to engineers as customer development. (as an aside we’ve got Eric Ries in conversation at Atlassian Summit 2012)

Product Owners Calendar

(Slide 8)

Lacking customer interaction. The Scrum definition of Product Owner doesn’t define anytime to sit with customers except for the time that customers join the demo and planning each sprint. Don’t confuse the customer showcase for the entire market.

If you are the PO that doesn’t get out of the building you failed. Yet Scrum training expects you to sit with the team and be able to answer all of their questions about the customer/problem.

“get out of the building” - Steve Blank

Agile will consume much more product management time – which is good. But if all you do is sit with your team – EOJ – End of Job.

A “small p product owner” lacks real input from execs, customers, etc and that  is a failed model.

Most Product Owner failure is due to not spending enough time observing customers, or they don’t know how sales and marketing work, or we promoted them from development and they are missing pricing, packaging, EOLing experience, competitive dynamics, and more.

Generally a promotion from engineering to PM  doesn’t have good connections to sales, marketing, support – all of which are a great source of input. Don’t just promote someone who is a good engineer to a PM – you lose a good engineer and don’t necessarily get a good PM.

Another challenge for the Product Owner is that they haven’t spent enough time with company strategy – optimise locally vs optimising a company wide strategy. Or you have a solo product manager who doesn’t prime the backlog – “build what I meant” – the PM who doesn’t know Agile.

So, really there should not be a split between the PM/PO roles. Fewer more experienced people works best.

Waterfall is conceptually easier as you believe in the fiction that the projections are correct, until 6 weeks before launch. A lot of companies run on Waterfall at the top and Agile at the bottom, and there is something bad that happens in between.

Technical Skillset

What are the weapons that a PM needs to have to work with engineering?

  • If you are not very technical don’t sign up for a technical product management job until you’ve built the technical foundation.
  • Engineers listen to you a whole lot more when you come from an Engineering background as you can call BS.
  • A technical team will write you off in a second in a highly regulated environment (finance/medical). Engineers will know if you are talking BS.
  • Consumer apps need a PM with a lot of taste, they need to know what the demographic cares about. Tech background is not as important.
  • Hire MBA’s in their second job out of college – so they no longer think they are the boss. Great hires if they have a technical background.
  • Helps to have a friend in the development team, even if not in the same company. You can ask the questions without showing too much weakness.
  • How can you gain technical skills? Start hacking. Build it now. Startup weekend.

How to transition from project management to product management? 

The job of a project manager is to get done the things we’ve promised to get done when we know we don’t have enough time or resources – how can we shave the edges to ship the thing we promised to ship? Can we shorten the QA cycle? Inward looking optimisation.

If I am on the product management side I ask what features to I drop to make the date? Outward looking optimisation.

Start spending more time with customers. Think about the pricing problem, competitors.

It is just as hard to go back the other way.

Better yet, build a team with complimentary skills. Have trust and happiness.

Resources:

Appreciate the notes? Please

Rory Sutherland on Behavioural Economics

April 16, 2012 in Product Management with Comments Off

A 40 minute video I recommend you watch. It has got me thinking today, thinking of ways to frame products. There is also a TED Talk for those who are interested in learning more.

Have a watch and let me know in the comments what changes you plan to make to your product lineup as a result. Or perhaps you’re an old hand at all this behavioural economics stuff and can share a success story.

Atlassian Summit 2012

April 15, 2012 in Agile, Events with Comments Off

This is going to be big!

Atlassian Summit 2012 has a swag of great speakers. I am particularly excited about the Scrum / Kanban track which I am hosting, plus the DevOps, DevSpeed and Collaboration tracks. Speakers include:

There are a whole host of other folks as well. In short, I’m excited!

There will be a tonne of GreenHopper Gurus there, and we’re looking forward to talking Agile.

SF Product Talk April

April 11, 2012 in Agile, Product Management with 4 Comments

If you are a product person swing by the Atlassian office tonight from 630 for SF Product Talks. You can RSVP here.

We can talk about whatever you want to cover, and if we don’t get to it this time we’ll add it to the list for the May meetup. Some topics to get the discussion started tonight:

UPDATE: Slides from SF Product Talk April are available here: SF Product Talks – April 2012

The takeaway for me was the risk register for a volunteer run project spanning many months – you had to be there, I can’t divulge the secrets!

Building a Strong Product Culture

March 26, 2012 in Agile, Product Management with 1 Comment

Last Thursday night I was fortunate enough to see Marty Cagan of the Silicon Valley Product Group speak at an event just around the corner from Atlassian in SOMA. I thoroughly enjoyed reading his book - Inspired: How To Create Products Customers Love - so seeing him speak was great!

On Thursday Marty spoke about the importance of building a strong product culture within a company. He explains that a strong product culture is one where the company is constantly developing and delivering new revenue streams.

Marty went on to describe a number of areas that strong product cultures excel at, I thought of these as similar to design patterns - ie, formalised best practices that you should implement in your organisation. That of course means there are also anti-patterns. Lets start with one of those:

the single biggest reason for product failure is gathering requirements. don’t confuse what the customer asks for with what their problem is.

A product managers role, and the role of the whole team, is to invent a solution on behalf of the customers. A successful solution is one where you have a number of happy reference customers for the MVP.

Now we will turn our attention to some patterns of strong product cultures.

Define Success Upfront

How does a product manager ensure that they are going to have happy reference customers for the MVP? Define success upfront. Build a hypothesis that you want to test and specify the success criteria prior to writing any code. Let’s take a look at a simple example of a login page for a consumer SaaS:

We have a user story:

As a user I would like to log in with my Facebook account so that I only have to remember one username and password

This user story will also have acceptance criteria:

  • display the Facebook logo on the login page,
  • return to the login page if incorrect username & password are supplied,
  • provide error message
  • etc

The acceptance criteria is there to ensure the team is clear about what they are delivering to the customer.

Now, let’s add success criteria to that user story:

  • ‘new user signups increase by 30% due to the simplified signup/login process’
  • ‘requests to the forgot my password page cease’
  • etc

Thus our user story has acceptance criteria and success criteria.

Instead of rolling out this change to all customers at once we will extend our definition of done to include meeting the success criteria. The team will then A/B test the user story with our customer base to ensure that the success criteria is met by the cohort that sees the new login page.

Assuming the cohort that sees the new login page leads to 30% increase in conversion and no password requests we would then consider the user story ‘Done’ as it meets both the acceptance and success criteria. We would roll the user story out to all customers. Of course, if our success criteria was not met then we will reject that story – perhaps leading to a subsequent hypothesis in another story.

To visualise that these user stories have not met the definition of done yet you may have a board like the following, with a column for ‘In A/B’:

This approach to defining the success criteria upfront is a great method to ensuring that features which are released to customers are actually worthwhile, actually used, that they provide value to the customer.

Product Discovery

Product Discovery is an approach to quickly testing and validating our ideas. Every product manager I have ever spoken with has more ideas that they want to build and provide to the customer than they could ever possibly deliver. While this is intertwined with Defining Success Upfront (above) it is really in the pre-user-story stage such as when we are aiming for an MVP. We don’t want to write production code for all of the ideas that we want to test as that is costly and leads to a lot of waste. Instead, we can do one of the following:

I won’t got into detail on the paper prototypes here as I’ve linked to a great intro video above. You can also read a follow up post on usability testing with paper prototypes which gives some examples.

The live data prototype is similar to the A/B test that we put the user story through above. The key difference is that we are not writing production quality code – no unit or functional tests, for instance. There are two questions that the live data prototype will help us answer:

  • Could the customer use the functionality?
  • Would they use the functionality? If not, what would it take to get them to use it?

It is key that you are asking the customer whether they would use the functionality – for instance, would they pay for it? If not, why not?

Product Managers have a tonne of ideas they want to try out. This Product Discovery process is essential to finding out what resonates with your customers, what they can use and what they will pay for.

Product Discovery Team

Finding new product opportunities takes time and energy. Having a Product Discovery Team dedicated to this task will enable existing product teams to focus on optimising the value to their customers while still allowing the company to approach new ideas for testing and validation. Of course, this depends on the size of the company – perhaps you’ve got time to cover these alongside existing products or perhaps you’re a new company trying to find the MVP for your product.

In either case the Product Discovery Team will require three roles:

  • Product Manager
  • Lead Designer
  • Lead Developer

Together these three come up with a solution to the customers problem. It is rare to find two of these roles in one person – hard too as they are probably out doing their own thing already.

One takeaway for me, from Marty’s talk, was that you should lead with UX as it is likely more important than engineering. I’m starting to see the constraint on UX, there are not enough good people and they are the bottleneck for many teams.

Random Tidbits

  • Bring at least three customers into the office each week, watch them use the product and use this as an opportunity for product discovery. It can’t help to bring customers closer to the team either.
  • You want a Founder / CEO that demands excellence. Better that than someone who doesn’t care about the product or customer and is only interested in the bottom line. Demanding pixel perfection is excellence – a real eye opener for me.
  • Really, there is no reason not to test something these days – you can run a test over a few days and have the metrics handy when you have a discussion with the Founder / CEO.

Recommended Reading

Conclusion

How can we come up with an experience worth building with the evidence to validate this?

At the end of the day the Product Managers role is twofold – customer discovery and product discovery. A product managers job is not to be right, it is to find out how to get to right, fast. Getting a new product into the hands of customers isn’t simply a matter of building something. It is much more than that, as we’ve explored above.

Once the product has launched the product manager will switch to an optimisation role – where the process is more iterative and defining success for new user stories is vital.

“think in leaps, iterate in steps” - Google

Build and deploy incrementally and iteratively, but make sure you have a compelling product vision. You don’t want to go faster and get nowhere – so make sure you have a vision.

Planning for whole of product UX changes

March 17, 2012 in Agile with 5 Comments

There is an interesting discussion on the kanbandev Yahoo Group exploring how best to plan and track UX work that impacts all of the features of a product. This would certainly impact the regular flow of the team if some UX work was going to have to be switched live on Day X. There are a number of constraints that Jose shares:

  • UX people are part of the team, their work must be visualised with the rest of the team
  • UX workflow is different to the user stories, no dev necessarily as it may just be investigation for future stories

In some respects you can leave a UX task like this on the board for a long time. Similar to an extended Sprint Zero.

I think a whole product UX revamp can still be broken down into manageable chunks such as Phase 1 / 2 / 3 / etc. You could then decompose that further into Design, Validation, User Testing, etc. Rolling out all of these changes on Day X can still be achieved although it would be difficult to batch up all of that work. Not to mention the waste as it sat there in the source code, unavailable to users.

Some suggestions:

  • use feature flags to roll out features one at a time and get feedback from beta customers
  • capture the value behind this feature flag until all of the features are ready to switched on
  • keep the whole UX revamp story on the board in a different class of service, visibility is key for the whole team
  • split out cycle time for this class of service so it doesn’t impact the rest of the board

Fun times revamping the whole UX for a product!

Speaking of which, GreenHopper 5.9.1 is available today. Our team has been hiding features from mainstream customers and only making them available for our beta customers. We slowly role new features out to all customers as they ‘solidify’ – not the whole product at once, although over time it will end up in a whole product UX revamp. So, I understand where Jose and the others on kanbandev are coming from.

Now Listing Jobs

March 7, 2012 in Job Opportunities with Comments Off

Chatting with customers recently it seems like good Product Owners, ScrumMasters, Developers, etc with Agile skills are in high demand. To help great companies find great people I am going to compile a list of all the openings I am aware of to get the word out – you’ll find them on the Job Opportunities page.

If you want to add a job to the list let me know. If you are looking for a new gig then just reach out to the companies directly.

Have any thoughts on how I can make this better? Let me know in the comments below. Thanks.

Epic Visualisation for a Product

March 7, 2012 in Agile with Comments Off

Today I received an interesting email from a GreenHopper customer. Thushara Wijewardena of Exilesoft and her team were wondering if we have a visualisation similar to the following:

At first I was unsure how to interpret the chart, suffice to say it had high information density. Thushara explained that the goal of the above chart is to provide visibility into a product, in this case a feature release roadmap. Thushara could easily do this on a physical wall, although the cost and effort involved in keeping it up to date for four teams in different geographies would be significant. Hence the desire to pull the information from GreenHopper and JIRA, as the information is readily available.

What does it all mean?

  • The circles represent time periods. In this case each circle represents a 3 month timeboxed feature release. The inner circle is the current release, and then there are four future releases in the planning stage.
  • Outside the largest circle is the unplanned wish list of features. The order of these items on the backlog is not shown on the chart.
  • Each section of the circle represents one component. This shows the distribution of work across various components of the product so that you can see at a glance if you are spending too much time in one area.
  • Red notes represent those stories that the team has not estimated yet. Red can also mean that the team has a problem with those stories and they need the product owners attention.
  • The order of the items on the backlog is not shown in this chart.

I think this is a really neat visualisation. The sections remind me of epics, spanning many releases, and the distribution of stories within each epic quickly shows me how much I am spending on each. Until the email today I always thought that a parking lot diagram was the best way to display this information. While the information density above is greater I can see value in both approaches. An example parking lot diagram from Agile blog Leading Answers is shown below for comparison.

How do you visualise progress on your epics? Let me know in the comments below.

Neither GreenHopper or JIRA contain a visualisation like this today. With the new REST API’s and Alex’s recent writeup on the new architecture of GreenHopper I can’t imagine it will be long before we see something on the Plugin Exchange.

Atlassian User Group – February 9, San Francisco

February 19, 2012 in Agile, Events with Comments Off

Just a quick wrap up on the first AUG in the new Atlassian office in San Francisco:

  • There were a bunch of people, 80 or 90 odd – super turnout!
  • Lots of hands went up when I asked about GreenHopper users.
  • Not as many people using GreenHopper for Kanban as I expected.

It left me wondering two things:

  • How quickly are you, our GreenHopper customers, able to adopt the latest version?
  • Are other teams in your organisation picking up Agile practices from the software development teams?
  • How do we spread Kanban into sales, support and operations teams? They should all be using GreenHopper!

Your thoughts welcome in the comments below. If you have any queries about GreenHopper best to add those to Agile Answers.

Word of the day: Extirpate

February 15, 2012 in Agile, Recommended Reading with Comments Off

Just saw that in the latest Forrester report on Agile – Determine The Business And IT Impact Of Agile Development by Diego Lo Giudice for Application Development & Delivery Professionals (February 8, 2012).

Nice word.

Page 1 of 41234»