Frameworks and Methods Made Simple For Busy People

I love reducing superfluous methods to their essence.

It's something I've grown to enjoy from working tirelessly for executives who swear they have no time but are serious about transforming their business. Who could blame them?

A market has been created from making methods sound more complex than they need to be. Just when you think you're up-to-date, they've created more fancy names for broadly the same thing with some minor variations in tools. They've found more words to politely nudge audiences into relentless focus on the customer and effective team operations.

You enroll for yet another multi-week course which awards a certification for the latest methods. Weeks go by, and you're thinking, "This all feels very familiar." Meanwhile, the executive who doesn't have the time turns to Google to sound knowledgeable with the textbook definitions of "Agile", "Product Owner", "Customer Journey".

In the next 5 minutes, I summarise the key lessons and reminders and leave you with terms you can Google in your free time to be a pro in innovation, human-centred design, agile, lean, scrum.

I promise it's so unbelievably simple once you get straight to the point. Let's go!

---

Frameworks And Methods Simplified

Before you get your hands dirty creating the next big innovation and possibly even your very own startup, it's worth dedicating time figuring out why (your intentions, desired impact).

(Google: "Start With Why")

This keeps you grounded and outcome-focused. And more importantly, "Why" keeps you inspired when self-doubt sets in.

[Why: Check]

Once you've got the "Why" sorted, it's time to observe and interview your prospective customers.

(Google: "POEMS framework", "5 Whys")

You may have heard of the phrase "The customer is always right". Well, that isn't true all the time. When customers say "I need this", they haven't told you the problem. Rather, they've just told you what they have tried and failed given the circumstances. It's up to you to figure out the real problem (the real job to be done) through observation and skilful questioning.

[Job To Be Done: Check]

With the interviews out of the way, you quickly get started on the most exciting part - brainstorming possible solutions. The excitement and tension can get the better of you. When that happens, redirect your attention to "Why" and the "Job to be done". Are you designing something to fulfill your ego? Or are you solving your customers' problem?

Ultimately, your products and services have to be desirable, feasible, viable. In other words, you must be able to run a profitable business by delivering on your promises without killing yourself or your team. Your products and services are not great because you have spent lots of time on it. They are great because they solve the customers' real problem in the most unexpected simplest way.

(Google: "Business Model Canvas", "Jobs To Be Done", "User Stories", "Desirability Feasibility Viability")

[Business Model: Check]

All creators take pride in creating a great product or service. So much pride in fact, they create a dedicated job title for them called the "Product Owner".

Product owners put their heart and soul into figuring out what matters most for the customers. They draft what's called "User Stories" which basically outlines what type of customers has a job to be done to solve which problem or to yield what benefits. Keyword here is "Done". Unless you fancy rework and misunderstanding, your teams need to have a common understanding of "Done" from the customer's perspective.

“As a [persona], I [want to], [so that].”

Classically trained technologists typically focus on documenting [want to] and if we are lucky, [persona]. This is a little like writing test scenarios at the planning and design phases, but with a deliberate callout for outcomes for the customer (the [so that]). Done consciously, you will stop delivering random functionality and start enabling client benefits in a cohesive and thoughtful way.

[Product Backlog & Prioritised User Stories: Check]

Amidst balancing what the customer demands and what the team can reasonably deliver, product owners often miss designing the other things that matter - the customer interactions with all the functions and other external partners.

(Google: "Customer Journey", "Business Model Canvas")

Your customers aren't going to rate your product favourably if your delivery partners fail to deliver on time, your after-sales service is non-existent, and no one can tell them how to get a refund. So no one forgets, there's another template for you called the "Customer Journey Map" to chart how our customers actually feel about what we're doing.

[Customer Journey: Check]

While there's the "Product Owner" who ensures a desirable end product, there's also the "Scrum Master" who works with the development team. Like all decent managers, Scrum Masters ensure there are no rude surprises, no misunderstandings, and no hard feelings.

(Google: "Kanban", "Sprint Planning", "Daily Scrum", "Sprint Review", "Retrospective")

Yes...it's that basic. They have fancy names for different ceremonies but essentially these exist to work toward:

• Smaller, more manageable targets (called sprints) which are achievable within a shorter period of time and more accurately planned;
• Common expectations of what needs to be delivered and when;
• Demonstrations of what has been completed vis-à-vis the "jobs to be done"; and
• Honest reflection and commitment to reinforce what works well and change what doesn't work well.

Speaking about honesty ...

Let's be honest. There's no way you can accurately estimate a big project the first time...

You only have enough information to estimate small and imminent work. Everything else is a best-effort forecast which needs to be refined. Estimates improve as team members begin to understand each others' strengths and weaknesses, and understand "Done" in the same way.

(Google: "Agile Estimation Techniques", "Sprint Planning")

In the spirit of no surprises, the team agrees on a small set of prioritised user stories which can be reasonably developed within 2 - 4 weeks. They work hard at arriving at a common understanding of "Done", refining estimates and assigning team members.

Finally they get to work!

Tools are used to visualise work as it changes hands and scrutinise build-ups of work-in-progress user stories.

(Google: "JIRA Kanban Board")

In 15 minutes (daily), everyone knows what the team is working towards, what's been achieved the day before, what will be worked on and by whom for the day, what help may be needed that day. In the spirit of no rude surprises, confessions of help requests are best delivered at the start of day so no one's scrambling and getting their evenings ruined.

(Google: "Daily Scrum")

When activities shift into high gear, one can expect cracks and backlogs to surface in tasks which are manual or handled by less experienced or 100% utilised resources.

(Google: "LEAN Bottleneck Analysis")

There is no shame in raising your hand to signal for help or to offer help. No one's going to blame you. We're only at fault when we choose stay silent. Never leave it till it's too late to call for help or to offer assistance.

(Google: "Emergency Kanban")

When the dust settles, the team reflects on what worked and what didn't work. The intent is not to blame but to be better the next time.

(Google: "Scrum Retrospective")

[Effective Collaborative Team: Check]

After a few sprints, the Product Owner musters enough courage to say, "Yes, I believe we have just enough to launch version 1.0. Let's not wait till we think we're perfect to get our customers' views. Let's show them what we've got."

(Google: "Minimum Viable Product")

Build it. Test and measure results with customers. Learn from it. Repeat.

You want to get your first version (albeit scrappy) out there sooner rather than later. This allows you to know if you are really close to solving the problem or are completely on the wrong track. The latter is so costly! So the sooner you seek feedback with something tangible, the faster you adjust or move forward confidently.

Expect to fail from time to time.

It's perfectly normal but what isn't normal is to move on as if the failure never happened.

(Google: "The Lean Startup", "Build Measure Learn cycle")

If you aren't intentionally figuring out and sharing what worked and what didn't, then you're just wasting precious resources and time. You and your company will have truly failed... repeatedly. Other teams will be designing multiple similar experiments and annoying your customers with products which do not address their problem and the customer experience.

Consider this ...

If your first attempt delivered "No...." and "Ok". You want it to become "Oh Yes!" and "Wow". You ought to get better. You don't want the next attempt to become "Arghhh" and "Go Away".

(Google: "Diverge Converge")

A truly collaborative learning organisation comes together to combine the best of what they've tried over multiple experiments to deliver a more superior experience for the customer.

[Learning Organisation: Check]

The end result? A desirable product or service which keeps customers loyal and eager for more.

Summary

There you have it - the spirit of Lean Startup, Human-Centred Design, Scrum, Agile combined into a few minutes. You didn't get certified by reading this, but hopefully this gives you enough to select targeted areas you will like to explore.

A lot of this sounds pretty basic for anyone who naturally cares deeply about their customers and their teams (internal and external), speed and effectiveness. That's because it is!

So why do we need frameworks, processes, tools, templates?

They were created to tell you politely repeatedly and visually with data:

• "I hope you know why you are doing this? Because it's not making any sense."

• "Don't take their word for it. Your customers neither know what their problem is nor what the ideal solution is."

• "Your product or service is worth nothing till it has been successfully delivered and used by the customer."

• "Your customer finds this really annoying ..."

• "Stop adding bells and whistles which don't matter to your customers."

• "There's no such thing as perfection."

• "Stop killing your team with vague and unreasonable asks."

• "Be honest about what you're working on. You'll have to prove it soon."

• "It is your job to signal for help. No one should have to suffer in silence."

• "If it's not working, let's change it."

They sincerely hope routine ceremonies and templates will help promote the right focus and culture.

So what if you have certified coaches for every new jargon they create? So what if you have teams ensuring you have every customer journey plotted and version controlled?

All these processes, meetings and templates could all be a waste of time if you simply refuse to address 3 key questions:

How will our customer feel about this?

Are we all clear and reasonable with what we set out to achieve?

Are we committing the same mistakes?

So is it worth the time?

If you are an engineer, then definitely explore human-centred design in greater detail. Time permitting, check out Lean Startup.

If you are in a customer-facing job or have never worked on a project, then perhaps explore Agile to work effectively with others on the project team.

If you are an aspiring business sponsor, Lean Startup is definitely for you. Have a go at filling out your very own Business Model Canvas!

Happy learning!