Posts Tagged ‘Product Management’

Strategic Project Management Made Simple

Posted: Jan 1, 2021 in Book Reviews, Product Management
Tags: , ,
0

This was a good read by Terry Schmidt, with some fantastic practical tools such as the LogFrame used for strategic product planning, which also generates a hypothesis.

A good alternative to the VMOST framework.

Agile over Scrum or Kanban

Posted: Dec 13, 2019 in Business, Product Management
Tags: , , , ,

Agile

Whilst Agile frameworks such as Scrum and Kanban are a great way of taking steps towards becoming more Agile, it’s important to remember amongst their own principles and guidelines, that the ultimate objective is to deliver customer value/the product vision in an efficient and competitive way.

To help avoid losing sight of this objective and falling into the trap of obsessing about the intricate details of the frameworks too much, it’s important that gap analysis is done frequently on the actual Agile manifesto and principles themselves to see how you can shape the Agile framework to achieve agility and the real benefits of being Agile.
The 4 Agile Values/Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The 12 Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How Spotify have adopted Agile

Agile Product Ownership in a Nutshell

Posted: Sep 3, 2018 in Business, Product Management
Tags: , , , , , , ,
0

Ownership

The product development lifecycle is complex, but in order for it to run like a well oiled machine there needs to be solid product management at the heart.

The below video explains Agile Product Ownership incredibly well and covers:

A typical Product Manager R&R would also be:

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Epic breakdown to user stories
  • Requirement workshops and documenting them
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

More info here on how to scale product when the time is right.

Ceremonies are a Scrum teams bread and butter

Posted: Jul 18, 2018 in Data, Product Management, Web Design
Tags: , , , ,
0

ScrumCards

A self-organised development team working together successfully to achieve common goals within the sprint boundary (typically every two weeks) is only possible if the teams ceremonies are done which includes:

  1. Daily stand-up – the scrum team need to meetup daily on time to discuss what they did yesterday, what they’re planning to do today, highlight any dependencies, issues or help they might need
  2. Updating the scrum board daily – whether the source of truth is the physical board or a digital version eg. JIRA, the scrum board needs to reflect the current state of play with regards to the sprint progress, so the team can understand how they’re progressing with their sprint commitments and sprint goals
  3. Regular backlog grooming sessions – in order for the development team to be able to work on the highest priority PBIs (Product Backlog Items) in the next sprint, they need to ensure they meet up regularly in order to get at least the next three sprints highest priority backlog items in a ‘ready‘ state
  4. Roughly sizing the backlog – in order to predict when customers will receive tweaks to the product, it’s important that the product backlog is roughly sized to aid delivery ETAs, but also prioritisation
  5. Retrospectives – meeting up once a sprint to discuss what could have gone better in the last sprint, what went well and what to continue doing. The format is flexible and the most important thing to do at the start of any retrospective is to focus on actions front the last retrospective – unless actions are done (the team learns), retrospectives are pointless, so it’s absolutely crucial that the things which the teams are keen to change / improve on is actioned or tried at least.
  6. Sprint review – showcasing what awesome iterations the team has been working on to get feedback and a round of applause from stakeholders

In order for the scrum team to be able to fulfil their commitments they should be getting significant help, guidance and support from the Scrum Master or Team Lead, Product Manager and the Development Manager and only once the above points (basics) are being done well, can a team start to seriously look to improve their velocity and scale successfully.

Scrum vs. Kanban

Posted: Aug 2, 2016 in Business, Product Management
Tags: , , ,
0

Scrum

Development teams should decide what agile development framework they adopt/try out using retrospectives to aid improvements and change.

The way teams operate is significantly different between Scrum and Kanban, but the fundamentals of business delivery stay the same eg. Prioritisation, frequency of delivering value to customers, agile software delivery and development team structure/support. So what are the differences:

Scrum

  • Scrum is one of the most popular ways to implement Agile. It is an iterative software model that follows a set of roles, responsibilities, and meetings that never change. Sprints, usually lasting one to two weeks, allow the team to deliver software on a regular basis.
  • Teams commit to delivering two weeks worth of work, but if the original plan changes by even adding work, removing work or changing work / stories within a sprint would mean the team fails in achieving the original sprint commitments / goal
  • If teams deliver what they commit to then they celebrate passing the sprint (which was the sprint goal) ie. a teams goal is to deliver on their sprint commitments, not to get the actual development / value live to customers
  • Set Scrum ceremonies such as daily stand ups, fortnightly sprint planning, fortnightly backlog grooming and a retrospective
  • Sizing user stories which can be a different size
  • Sprint burndown charts to measure progress
  • You have a team velocity to help set realistic future sprint goals and project feature ETAs
  • Normally there can be no dependencies when committing to work in a sprint so even more upfront planning / scheduling / grooming is needed

Kanban

  • Kanban, meaning “visual sign” or “card” in Japanese, is a visual framework to implement Agile. It promotes small, continuous changes to your current system. Its principles include: visualise the workflow, limit work in progress, manage and enhance the flow, make policies explicit, and continuously improve.
  • The goal is to move user stories / bugs through different stages of the development cycle with the goal to get the story from one side of the board to ‘live’ / ‘done’ ASAP
  • The stories high up in the backlog / coming next should be broken down so that each piece of work is roughly equally sized allowing you to gauge an average story cycle time and deliver value frequently
  • The team are typically not bound by time limits to getting work done and instead restrict WIP by dev status to ensure value gets delivered frequently to customers
  • Grooming, stand ups, planning and retrospectives are not mandatory but regular grooming, stand ups and retrospectives are recommended to ensure efficiency is at a good level
  • As there’s typically no fixed deadline on work getting done, teams can spend longer on thorough investigations into multiple solutions if needed. Also on the other end having a column on the Kanban board for demos, pre-production work and a column representing live is also possible allowing stories to be closed only when value starts getting delivered to customers
  • Because of the above, it makes the status of development work crystal clear rather than a sprint ending and you having to dig around to find out where it is and spend more effort / create additional release stories trying to get it live
  • The team lead and dev manager role is even more important to ensure the team are trained up, working efficiently and resourced to get the job done
  • As teams pick work from the top of the backlog adhoc, it’s likely a new highest priority item will be picked up sooner than if it was at the top of a Scrum board as you don’t have to wait two weeks until the sprint finishes before it’s in development

Both Scrum and Kanban have plenty of pros, cons and bring different challenges to the table, but give software engineers the autonomy to get through the backlog without sprint boundaries or artificial deadlines then you’ll likely see productivity, quality and communication increase, with the caveat that they must have strong support from the team lead, dev manager and product manager who aren’t afraid to get stuck in.

Relationship between marketing and product development

Posted: Jul 18, 2016 in Business, CRM, Marketing, Product Management
Tags: , , , ,
0

With marketing departments typically focusing on P&L / ROI of ad campaigns and product development on product quality, product feature enhancements / performance and customer UX, it’s easy for the two business areas to be fragmented which could make the end goal harder to reach.

Ironically although the individual department goals for both are normally so separate and different, the most common problems they face can sometimes be solved by the other eg. Acquisition marketing unable to increase incremental volume because the CPA / ROI / ARPU of the additional media spend doesn’t look healthy, yet fixing some bugs around the product feature in question, a feature enhancement or a new product release is likely to contribute to the solution that allows a raft of new customers through the door efficiently. Vice versa, a new shiny product or feature where the target audience is so niche that acquisition marketing efficiency / volume is poor or it’s unlikely existing customers will benefit, then it’ll be an uphill struggle to make the product viable.

Fortunately the majority of brands have both of these areas in-house so it does make optimising the relationships and responsibilities easier. Naturally one area cannot exist without the other even when you look at brands like Google and Facebook who have groundbreaking products, yet still require nicely crafted ad campaigns to generate incremental revenue.

Product developers don’t bite and marketers don’t just care about ad campaign performance, so close collaboration which is vital can be achieved by letting down a shield and discussing problems openly and bravely, so that multiple solutions can be discussed and you never know, the problem you thought was a tough problem to solve, may not be so tough anymore.

Again, close collaboration is key and potentially another way of aiding / fast tracking an improved relationship is by recruiting a marketer or two into the product development arena or vice versa.

The two departments working collaboratively to solve problems could lead to some spectacular chemistry.

Consumer experience is the future

Posted: Jun 12, 2013 in Business, Marketing, Product Management
Tags: , , , , , ,
0

satisfied_customers

No matter how much marketing you deliver, whether it’s billions of banners on the most premium sites in the world or you’re top of key generics consistently for Google, unless you have a stable product offering which customers genuinely embrace, then your brand has a fairly bleak future.

Historically you could spend your way out of a crisis, but now if your site crashes often, you hide key T&Cs, mis-sell promotions, have a complex user journey, product not available on multiple devices, then in a few years time your brand value will show a clear decline which would eventually kill your business unless you adapt fast.

I think the below video demonstrates the future in a fantastic way and how consumers will shape products, businesses and communication. The good thing about the future is that it will kill a lot of cow boys who are short sited and have no long term business strategy.

Newer Entries