In this article, I’ll give my 2 cents to demystify some concepts in this area, and I try to explain how we — at Landing.Jobs — are using these mindsets to develop a better product that people want to use!
Why these Mindsets work better together
According to Jeanne Liedtka, a successful innovation process must deliver three things: superior solutions, lower risks, and employee buy-in.
Each phase in an innovation project comes with its own uncertainties in terms of known knowns, known unknowns, and unknown unknowns. Mindsets, methods, methodologies, and tools such as Design Thinking, Lean Startup, Design Sprints, Prototypes, Minimum Viable Products (MVPs), Business Modeling, and Agile do a great job of mitigating the risk of a project while ensuring high quality since they encompass the knowledge that ideas must be validated, and no one is so smart as to be able to do it alone nor before testing it within the complex environment where it will live.
So, the question is: which one(s) should organizations adopt?
Several authors argue that the choice to use Agile, Lean, or Design Thinking is heavily influenced by the problem to solve and by the tools that people readily know how to use and are comfortable applying. That is why different people tend to favour different approaches — engineers and software developers prefer Agile, entrepreneurs favour Lean, and designers favour Design Thinking — it’s all about their background and how they try to frame a problem to fit a context they are already familiar with.
However, the correct answer perhaps should be “and”: Design Thinking “and” Lean “and” Agile.
- The Design Thinking mindset can help companies discover what people want. It is about finding opportunities and exploring different possibilities.
- The Lean mindset can help companies understand if there is a market for the idea (remember: producing products nobody wants is not a good idea…).
- The Agile mindset is how the engineering team can develop software that people can use and gain benefit from immediately.
Jonny Schneider summarized well how these approaches could be put together in his book “Understanding Design Thinking, Lean, and Agile”. The strengths of each mindset come together to help us achieve the right outcomes.
Right now, perhaps you are thinking, “this article is great, but it’s all talk and no action”. So, I will now explain how we are using these mindsets at Landing.Jobs.
Practical Application of Design Thinking, Lean, and Agile
Before starting, I should make my point clear that there is nothing to be gained from dogmatic adherence to a particular right way to do things. In fact, contrary to what many fanatic professionals might lead to think, most of these approaches have specific indications that they are not to be taken word-for-word and that adaptation is the key. Each company has its peculiarities, and so, companies should play to their strengths and existing skills. After all, success is not about mindsets or processes but People.
Applying all this in an innovative project
At Landing.Jobs we try to apply these mindsets whenever possible.
We use the principles of Design Thinking to identify our target audience and their pain points. We use a Lean approach to test the hypothesis raised. And finally, when we know that there’s a demand for the product, we develop the solution using an Agile mindset.
Below, I present several techniques that could be used by any company. More than that, I present a concrete example in which we applied such techniques.
Week1:
Day 1: Define Problem and Research Users & Domain
We started Day 1 by agreeing on the long-term goal — “What is the problem we’re going to solve??”, “Why should we try to solve it?” — that was to provide better and more accurate information to individuals related to the salaries and skills that the market is offering and looking for. In that way, we expect to increase the number of visitors and the recurrence of such visits.
After establishing the goal, we designed a map with the current user’s journey and all the pain points found during that flow.
Having captured such information, we used the How Might We technique to capture the best opportunities to address such pain points.
Day 2: Define — Choose a specific focus, goal, and success metrics
On Day 2, the core team evaluated everything they learned on Day 1 to establish focus. This was about finding the point(s) in the customer journey that is (are) most critical to get right.
Also, we defined some SMART goals for the initiative to have an idea of what this feature’s success might look like.
Day 3: Define — Generate ideas for possible solutions
On Day 3, the goal was to generate ideas for the pain points previously identified. We used techniques such as the Crazy Eights and the Solution Sketch to generate ideas.
Below, I present a sketch that was designed by one member of the team.
Day 4: Finalize the direction or concept to be prototyped
On Day 4, we finalized the direction or concept to be prototyped. Each participant shared the Solution Sketch, and the team found consensus on what should be moved forward and what should be rejected, at least for now.
Below, I present the Sketch for the consensus solution.
Day 5: Create a prototype of the concept
Finally, on Day 5, the team created a prototype for the concept. We have just made the prototype real enough to get an accurate response from a potential user in the Validate phase.
Below, I present a version of the prototype that was built:
So, we finalized Week 1, having an authentic prototype to be tested on Week 2.
Week 2: Validate, Iterate, Implement!
We started Week 2 by evaluating the prototype to see if we need to revise our hypothesis.
For that purpose, we created a simple survey using the “I Like, I Wish, What If” method to ask potential users to provide open feedback about the prototype.
Based on the feedback received, we made some adjustments to the prototype, ensuring that we were developing something that fulfils our Vision and is desired by our community.
Over the week, the Kanban delivery methodology gave us the agility needed to rapidly transform the prototype into a working piece of software in the hands of our users.
Final Remarks
Two weeks from idea to production! Did we develop the perfect solution? No! Was that even expected? No!
So, why did we do that? The image below can explain it.
Now you are wondering, “What…? But… How can you be satisfied when you want to build a car, and you have built a bike?”
Ohh… that’s easy!
- First of all, we have developed something that actually can help our community take ownership of their careers — so we are better than we were!
- Then, we learned many things along the way, which means we are developing the right thing.
- Also, in the meantime, our community is using the feature and giving us feedback.
- With that in mind, I am confident that we are a step closer to building the feature that you have dreamed of — in reality, a better feature than initially planned!
Oh… and I almost forgot to answer the questions that I raised in this post: The answer is “yes” to both assumptions — of course, there’s a lot of bingo buzzword, but the value of using these mindsets has already been proved.
After all, it is up to you to decide which mindsets fit your organization and how you can extract value from them because it matters not so much how you got there but that you did the right thing!
Rafael Almeida is a Product Owner at Landing.Jobs. As the guy from Sport Lisboa e Benfica, Rafael considers himself an avid problem-solver because one of his golden rules is that “when you’re attacking you don’t get as tired as when you’re chasing”.
0 Comments