What is Situational Leadership


Leaders need to adapt they management style to fit the performance readiness of their teams.

Paul Hersey and Ken Blanchard created the concept of situational leadership in the field of organisational behaviour.

They said that “readiness” not only varies by person, but also by task. People have different levels of ability and motivation for different tasks. Leaders can choose from directing, coaching, supporting and delegating depending on the situation and team member:

Situational_leadership

Directing

This style is recommended for team members that require a lot of specific guidance to complete the task. The leader could say: “Gerard this is what I would like you to do, here you have a step by step approach and here is when I need it done.” It’s primarily a command and control approach, one way conversation with little or no input from the team member.

Coaching

This is style is for team members who need guidance to complete the task, but there is a two-way conversation, the team member gives input. Coaching is for people who want and need to learn. The leader could say: “Gerard this is what I would like you to do, here you have a step by step approach and here is when I need it done. What do you think?”. Although the leader still set the approach, the team member is invited to give input and ultimately workout any change in the delivery plan if the leader and the team member think it will benefit the project.

Supporting

This style is for team members that have the skills to complete the task but may lack confidence to do it on their own. The leader could say: “Gerard, here is the task I need you to do and here is when I need this done. How do you think it should be done?, let’s talk about it, how can I help you on this one?. The leader knows the team member can achieve the task but s/he needs support to remove any impediment.

Delegating

This style es for team members who are motivated, have the ability to complete the task and have confidence. They know what to do, how to do it and can do it on their own. The leader could say: “Gerard, here is the task I need you to do and here is when I need this done. If I can help just ask, if not you are on your own.” Although is highly recommended to schedule health checks, the leader is confident the team member will complete the task based on his/her track record.

One style is not better than the other, each style is appropriate to the situation. Effective leaders know who is on their team, who can be left alone and who needs more direction.

5 Levels of Agile Planning


Within Agile, planning is done continuously. Planning is about working out what to do, and that must come before working out how long it will take.

In this post I would like to present a process that will allow team members to understand the whole sequence of planning from vision to user story.

5 Levels of Agile Planning

Level 1, Vision:

Every product needs a vision, a destination postcard that will guide the team towards the goal. The vision also helps to have a keen eye for opportunities, to focus on value (to the user and business) and return on investment (ROI). Every decision is taken with the product vision in mind. This ensures clarity for the development team and increases the chances of success.

Level 2, Roadmap:

This is a long-term product strategic roadmap (from 3 to 6 months max), this can also be explained by de-composing the vision into phases in a logical order. The roadmap will help to see how the product would evolve.

Note that it does not usually make sense to make a plan based on user stories that go further out than three months. Beyond this point, use a road map based on story themes.

Level 3, Plan Releases:

If the roadmap gives the phases, the release plan de-composes each phase into sprints. These sprints are conditioned by the roadmap; market conditions the status of the product. The product backlog consists on more than only features, for example: technical requirements, bugs, defects, spikes, non-functional requirements that should be taken into account.

Backlog refinement is very important, this must be granular and well understood by the whole team.

Level 4, Sprint Planning:

During the sprint planning the team plan and agrees the prioritised product backlog stories they are confident they can complete during the sprint and help them to achieve the sprint goal.

Here are 3 basic steps to create a plan:

  1. Understand priorities: Start with the team a conversation about the user stories the product owner would like to get in the next iteration to release.
  2. Size the work: 
When the stories are understood, help the team work out what needs to be done to deliver the stories.
  3. Agree on the plan: 
Wrap the meeting up by getting agreement on what can realistically be delivered.

Level 5, User Story:

If the team members want to deliver valuable software, they need to go the extra mile to understand both user and business benefits, and user stories help them do that. User stories underpin all the work an Agile team does, they are the basis of plans, development and testing.

The whole point of user stories is to ask questions to better understand what users need and to find ways of breaking requirements down. Break the tasks into smaller pieces so that everyone has a deliverable every day.

User stories are a simple technique that a team can use for understanding their customer through talking about what users need.

The main point is that Vision must drive decisions and User Stories are the means to achieve that vision.

Top Components of an Elevator Pitch


The elevator pitch is as important as the business plan, some people call it twitter pitch (but I think 140 characters might be too short).

Bplans explain what components a perfect elevator pitch must have; every single angle of a business plan in a short visionary version is laid out.

Top components of an elevator pitch:

1) Problem:

First you need to be clear about what problem your business will solve; without this there is simple no business. People require solutions to the challenges and issues they face. The definition must be simple and straight forward, so everyone can simply see the pain point:

  • “communication with remote teams can be complex”
  • “completing paperwork for a A&E doctor is time-consuming”
  • “filling out your tax return is difficult”

2) Solution:

When you have defined the problem, the solution needs to be explained. This also needs to be simple and focused.

3) Market:

Who is experiencing the problem you described?; it’s critical that you always keep in mind the persona you are targeting, their problem points, what pressing issues keep this person up at night. If your market is too big, then follow the divide and conquer strategy, segment you target market and prioritise the same.

4) Competition:

To have competition means that there is a market for the problem you are trying to solve, you also need to think not only on direct competition but alternatives. Like a wristwatch company competing with mobile phones, also think how well they solve your target market and which opportunities you have to differentiate your value proposition and positioning yourself differently.

5) Team 

People is far more important that ideas, people is what make ideas work. You need to explain how well this team can work together, what skills are they bringing to your company. You don’t need to have all the team in place but you need to understand what gaps you have and how you plan to close those gaps and when.

6) Financial summary

In here you basically need to clarify your business model; how you create value and how you convert that value into profit. Remember numbers never lie, be hard with your numbers, you need to do sales forecast and expense budget (these are based on assumptions).

7) Milestones

In here you present a high level plan, no need to enter in details but clearly identify large milestones / phases; their ordering, dependencies and when these will happen. This is the operational plan and it will picture your business as real as possible.

This great infographic from Bplans explains each component of an elevator pitch.

7 key components of a perfect elevator pitch

Source: The 7 Key Components of a Perfect Elevator Pitch [with infographic]

In Agile, What to do if Team Velocity is not as you Planned?


If after three or four sprints you notice your velocity is not where you had hoped it would be, do not panic. This might happen, this is why you need to set expectations accordingly and told your client not to trust your initial plans. The good news is that by the time you know about it, you can adjust course as necessary.

Team velocity

Being flexible about scope is the preferred method for restoring balance.

The important thing is to have the conversation and give your client some options. Yes, this may make you uncomfortable, but you can’t hide this stuff. Bad news early is the agile way.

There is one strategy for ensuring that when you do have the “too much to do, not enough time” conversation:

If you can’t deliver a minimalist version of the application with the time and resources you have got, then the plan is clearly wrong and needs to change.

It works like this:

  1. take one or two really important features for your project (something core that goes from end to end through your entire architecture) and
  2. measure how long it takes to build a minimalistic version of those features

Then use that against your remaining relatively sized stories to see whether a minimalistic version of the application is even possible with the time and resources you have.

If your dates are looking good, right on, if your dates are looking bad, great, at least you know about it now.

When you need to change the plan conversation from, It is not based on wishful thinking. There is no need to get emotional, it is just the facts. It is better to know this now than later.

In Agile, How to Handle New Client Requirements?


When your customer discovers what they really want in their project, ask them how they would like to handle it. You can push out the release date or add more resources (which is like saying we are going to need more money), or you can drop some of the less important stories from the to-do list (preferred).

Managing change requests

Don’t get emotional when you have this conversation. It is not your call to make. You are simply communicating.

Your responsibility is to:

  1. make them aware of the impact of their decisions and
  2. give them the information they need to make an informed decision.

If your client really wants it all, create a nice-to-have list and tell them that if there is time at the end of the project, these are the first stories you will do.

But make it clear, the nice-to-haves are currently off the table and are not going to be part of the core plan.

Agile Product Development


In agile product development is very hard to have the best product right away, so commit to rapid and continuous improvements is the way to go. Of course, the messiness of trial and error may seem uncomfortable, but action allows us to learn at a faster rate.

In agile product development avoid the paralysis by analysis
In agile product development avoid the paralysis by analysis

The following insightful story comes from the book Art & Fear by David Bayles  and Ted Orland.

A clever ceramics instructor divided his pottery class into 2 groups. One half of the students would be graded on quality and the other half would be grade on quantity.

Thought out the course, the “quality” students funnelled all the energy into crafting the perfect ceramic piece, they studied the right mix of materials, the correct measures, weight, optimal temperature, did an extensive research and produced one “perfect” product.

While the second half students do not care about the “perfect” product, but produced pots in every session non stop.

At the end, although it was counterintuitive to his students, you can guess how his experiment came out at the end of the course, the best pieces all came from students whose goal was quantity, the ones who spent the most time actually practicing their craft.

This lesson is applicable to a much broader view, if you want to make something great, you need to start making. Looking for perfection can get in the way during the early stages of the creative process. Do not get stuck in planing and start acting.

All the over-planing, talking are sings that we are afraid, that we don’t just feel ready;  that tendency leads us to wait rather than act, to perfect rather than launch.

* Image credit istock.com

Strategy and Customer Understanding


Your customer experience must support your corporate strategy. You need to work and focus on defining the customer experience that best aligns with:

  1. corporate vision,
  2. target market
  3. value proposition, your products & services
  4. unique strengths (competitive advantage)
  5. financial objectives
  6. core values

Be aware that the wrong customer experience would confuse your customers and send them to a competitor.

In addition to the strategy alignment, your customer experience must align with your brand attributes, you need to guide the activities and decision-making of employees at every level of your organisation, so that they can deliver on your company’s brand promises.

Companies need to understand and get a complete picture of what their customers really need, want and aspire.

Practices to understand client needs:

  1. mining unsolicited customer feedback, customers constantly provide unsolicited feedback about their experiences via emails, call, chats, social media, etc.
  2. conducting ethnographic research, this is simply observing your customer’s behaviour in a natural setting
  3. gathering input from employees, each of frontline employees interact with dozen or hundreds of individual customers and routinely witnesses with good and bad customer experiences.
  4. companies can create “Voice of the employees programs

As an example of a low tech approach, you can place whiteboards in prominent locations for employees to share ideas for improving the customer experience and track ideas from submission to implementation.

Thinking you know what customers want is risky. Most companies neglect to build a foundation of customer understanding before they develop products, services and experiences strategies, and then proceed with costly initiatives.

Employees and managers very often fall into the trap of assuming that what they want is what customers want.

To avoid this trap, you can:

  1. use personas to document who your customers are. Unlike market segmentations, which typically remain nameless and faceless, personas come to life with names, photos and vivid narratives that describe real life scenarios.
  2. once you have developed your personas, you create journey maps that visually illustrate a particular persona’s activities over time. You can plot the entire course of a customer’s relationship with a company or zoom in to just one particular part of the journey

But remember, you end goal is not the personas and journey maps themselves, your end goal is deep customer insights.

Once you complete this part, share your customer insight early and often, use all channels available and meet regularly with employees and business functions for all the company to be in the same page.

Read more: Outside In: The Power of Putting Customers at the Center of Your Business by Harley Manning, Kerry Bodine and Josh Bernoff. Forrester Research.

Digital Project Management and the 5Ds


The 5Ds in project management is a phase breakdown of large milestones that every project team needs to complete. This model gives a full vision of the tasks and deliverables for each phase.

This process is thought with Agile / Scrum Project/product methodologies in mind.

We call these phases the 5Ds:

Digital project management 5ds

Discovery: validates the business reason to kick-off the project, the benefits can be to revenue growth, cost reduction or risk management. Depending of the benefits these can also be short, medium term or strategic.

  • Define business value
  • Target market
  • Competitive analysis
  • Deliverable: Business Case

Definition: once the management team validates the importance of the project, a clear functional definition is required in order to specify the right set of user, features and business requirements.

  • Define personas
  • User stories
  • Technical dependencies
  • Information Architecture
  • Core functionality
  • Deliverable: User Stories and Product Technical Requirements Document 

Design: gives not only the look and feel to the solution but also aligns user and business requirements with the user experience. Why this is important?, imagine a disruptive user experience, this will affect the engagement and traffic to the Live solution and this at the end will put off advertisers, can you see the picture?.

  • Paper prototypes / sketches
  • Wireframes
  • Usability evaluation
  • Visual design explorations
  • Visual design approval
  • Deliverable: User Interface (UI) Designs

Development: the development, QA and product/user team start working every day, moving stories from backlog to the sprint and working together from technical analysis, development, quality assurance and user validation, this is an iterative process and is the core of the Agile methodology.

  • Architecture design
  • Daily scrum
  • Code iteration cycles
  • Usability evaluation
  • Release management
  • Unit testing
  • Code refactoring
  • Deliverable: Working solution and source code

Deliver: when the final user validates the solution, technical team performs performance testing and release plan, the full working solution is ready to be deployed to Live.

  • Case testings
  • Test reports
  • Build releases
  • Deliverable: Shippable release 

Remember that the project doesn’t finish when is released, the market will give important product feedback and is the job of the Agile product team to constantly improve the product by always aligning user experience and business objectives.

Business Tips From 37signals


Jason Fried is the Co-Founder and President of 37signals, a Chicago company committed to building the best web-based tools possible with the least number of features necessary.

37signals manifesto, as they say “It’s a collection of 37 nuggets of online philosophy and design wisdom. It’s a great introduction to the 37signals’ school of thought and a fun, quick read to boot.”

The book I read first was get it real and you can read it online and I strongly recommend it. This book really goes to the point and touches plenty of decisions that a business must face, even if it’s a large corporation or a small web factory.

My top posts are:

  1. build less
  2. fix time and budget, flex on scope
  3. lower your cost of change
  4. ignore details early on
  5. start with no
  6. hidden costs (new feature process)
  7. from idea to implementation (web app)
  8. epicenter design
  9. Hollywood launch
  10. promote through education

And if you really like this approach, you have to see this video from Jason, where he explains the following:

  1. Venture capitalists rents you time
  2. By pricing you will get great feedback
  3. Innovations come and go, stay focus on usefulness
  4. Focus on what won’t change, things that will pay off today and tomorrow
  5. DIY you have to do it yourself in order to hire or ask someone else to do it
  6. Apologise properly
  7. Nail the basics, that’s the real stuff
  8. Less is more, but make the few things you do really well

Digital Product Management


Almost every new service Google launches is a beta, a test, an experiment, a work in progress. Why? because launching and getting data from the market is the best way to improve a product.

Of course, the market can find errors, but companies must be pleased to get help to find those errors, for the company to fix them and improve the product.

The key on digital product management is iterations. When you launch a product, iteration with a well-defined audience is the best way to learn about the mistakes you made. The internet makes iteration and development on the fly possible.

The objective is to get the product out and then have the users to tell you where it is more important to spend your time.

Marissa Mayer, says “We make mistakes every time, every day. But if you launch things and iterate really quickly, people forget about those mistakes and have a lot of respect for how quickly your build your product up and make it better”.

Sheryl Sandberg, made an error while working at Google that cost millions, so she apologised to Larry Page who responded: “I’m so glad you made this mistake, because I want to run a company where we are moving too quickly and doing too much, not being too cautious and doing too little. If we don’t have any of these mistakes, we are just not taking enough risk”.

Dilbert Product Management