My product management toolkit (13): Continuous Discovery

I know it’s a bit of a bugbear of mine; people coming up with assumptions and jumping straight into solutions to address their assumptions:

“I know what my customers want” 

“I know that I’m right”

“I’ve got umpteen years of experience in this sector, I know what people want”

“We’ve defined all customer requirements, we now just need to implement”

These are some of the comments that I hear quite regularly. Hearing comments like these have made me even more determined to constantly discover.

Discovery is all about about truly understand what your customers want (and why) or validating your assumptions, checking whether what you think is actually true. I learned that “Dual Track Scrum” is a great way to do discovery in an efficient and a continuous way (see some visual breakdowns in Fig. 1 and Fig. 2 below). Marty Cagan introduced Dual Track Scrum, citing Jeff Patton as his inspiration. I don’t tend to get too hung up on the word “scrum”, because one might not always be working in a Scrum type fashion. It could be Kanban, XP or any other iterative development approach that you might be using instead.


Fig. 1 – Discovery feeding into Delivery – Taken from:

Instead, I like talking about ‘Continuous Discovery’, stressing that ongoing learning drives product development. Rather than doing big chunks of customer research at the start and at the end of the product development lifecycle, I prefer to learn ‘early and often’. The key is to spend some time understanding the problem first, before coming up with ideas or solutions to implement. With a ‘dual track’ approach, you’re constantly discovering and validating customer needs which can then be fed into the delivery of working software.

The outputs of a discovery track can come in all kinds of shapes and sizes:

  • A set of user stories and acceptance criteria
  • Design assets or wireframes
  • A prototype of a varying degree of fidelity
  • Learnings about user issues with working software
  • Data from a live experiment (e.g. A/B testing)

I often get asked why and when to best to use this Continuous Discovery approach and I thought to quickly summarise these FAQs:

Question: “Why can’t I just go and build stuff, launch and see what happens?”

My answer: I’d be the last person to stop you from building things, measuring and learn. However, I strongly believe that a large part of ‘continuous discovery’ is about mitigating (product) risk. Instead of spending a couple of weeks or months building something before you get actual customer feedback, I’d rather get customer feedback ‘early and often’, based on an product or a feature that has been used by actual users.

Question: “With these discovery sprints, isn’t there a big risk of ‘analysis paralysis’?”

My answer: No. By time-boxing and fixing the scoping of each discovery cycle, you can make sure that you constantly validate your riskiest assumptions or investigate things that can then go straight into the next development sprint. Each discovery cycle should result in a tested set of customer needs, user stories and/or wireframes which will then be converted into working software the following sprint.

Question: “Aren’t’ we just going over old ground?

My answer: From my experience, even if you have working software, by constantly testing it you’ll be able to fix bugs and develop a better product. It might seem tedious but I feel that this approach is a lot less risky compared to companies just doing a (soft) launch at the end of the development process and hoping for the best. Continuos discovery is not an alternative waterfall type approach,where you create additional stage gates and isolated process. In contrast, since development is still happening in tandem; you’re effectively discovering what needs to developing in the next iteration whilst people are building what you discovered in the previous discovery track.


Fig. 2 – Dual-Track Development – Taken from:

Main learning point: Instead of gathering customer requirements on a one off basis, I strongly recommend doing this continuously. Having designated discovery tracks that feed into development cycles will help in discovering customer problems and needs ‘early and often.’ This helps you in making sure that you’re building the right product for the right customer whilst you’re designing and building it.

Related links for further learning:

Leave a comment

Posted by on August 20, 2016 in Agile, Product Management


Tags: , , ,

Voice-enabled security and payments

I know I’m slightly late to the game when it comes to voice recognition technology, but I was intrigued when I came across a mobile banking app by Dutch bank ING, which they launched about a year ago. This app uses a voice enabled security and payments system, which makes it possible for its clients to check their balance or make mobile payments using their voice. In order to log in, users will have to say a short phrase which the banking app then matches to a sound file stored on the user’s phone.

The underlying claim here is that the shape of a user’s vocal cavities and the way a user moves her mouth means that speech can be more unique than a fingerprint. Nuance, a US based biometrics company, has developed technology that analyses a user’s voice “for hundreds of unique characteristics that are then compared to the voiceprint on file.”



Instead of having to remember 15,000 different passwords or related security questions – you should be able to tell my frustration with existing security measures here – Nuance aims to do away with all this by matching the user’s voice to a stored voiceprint. This can be either passively, whereby the user can say anything to enable the matching or actively, whereby the user is asked to recite a specific passphrase. As a result, authentication should become a lot easier and less stressful for the user.

From the perspective of a bank like ING or any other company, voice-based security mitigates the risks inherent in knowledge-based security. Four-digit PINs or event digital fingerprints can be easily compromised, for example when a person is attacked. Passwords and security questions can be successfully answered with simple web searches of the account holder.

In contrast, it’s much harder to compromise voice biometrics. A voiceprint is a hashed string of numbers and characters, which means that it’s pretty meaningless to a fraudster. Even more so, each time a hacker tries to speak with a call centre or a mobile app, their own voiceprint will be left behind which can then be used to proactively keep them out of the system.

Thinking of mobile payment giants like WeChat (see Fig. 1) and M-Pesa (see Fig. 2) and the rapid raise of in-app payments, I can see voice-based see voice based technology taking great a great flight over the coming years.

wechat payments


Fig. 1 – WeChat screenshot – Taken from:



Fig. 2 – “How to get started with M-Pesa” – Taken from:

Main learning point: I know that voice recognition isn’t yet where it needs to be in certain cases, but I can see how voice-enabled security and payments can provide a secure and seamless user experience, especially compared to issues related to the current knowledge based approach to passwords and security.

Related links for further learning:

Leave a comment

Posted by on August 7, 2016 in FinTech, Mobile, Technology


Tags: , , , ,

My product management toolkit (12): My 90 day plan as a product person

Soon I’ll be starting a new role as a Head of Product at a great FinTech business in London. I’m very excited about the role. There’s a lot of opportunity to make an impact and influence change. But where do I start? How do I prioritise change? These questions prompted me to start thinking about my 90 day plan for this role, identifying key steps and outcomes to concentrate on. I feel that the ‘3Ps’- people, product and process – are the most logical place for me to start from:


Objective 1: To assess current performance and ambitions of the people in the team and across the business; identify how I can help create the perfect conditions for them to do their day jobs and grow.

Key results:

  1. Individual audit and objectives-key results (‘OKRs’) – To understand strengths, weaknesses and development areas for each team member and have translated these into clearly defined goals and a personal development plan.
  2. Create a simple OKR measurement framework for team members (1) – I’m sure my new company will have a formal review framework, but I want to make sure that their specific quarterly objectives are measurable and are reviewed on ongoing basis beyond formal reviews once or twice a year. The goal is to make sure that personal OKRs are fully aligned with critical business goals.
  3. Create a simple OKR measurement framework for team members (2) – Even though OKRs aren’t necessarily meant to be a performance review tool, these will be very helpful in measuring and discussing personal progress. We can then make sure that individual OKRs align with overarching business and team objectives. I’ll have to make sure their objectives are highly measurable and feel somewhat uncomfortable, similar to the OKRs that I will set to measure my own performance (see example in Fig. 1 below).
  4. Hold at least 6 individual 1:1s with each of my team members within my first 90 days – Set a frequency and a clear agenda for regular 1:1s with my team members. I can imagine that different team members will have different preferences in terms of the frequency and content of our regular 1:1 sessions. I’ll agree this with my team members on an individual basis. I can imagine that our regular 1:1 sessions will cover a mix of OKR progress review as well any questions or issues related to day-to-day stuff.
  5. Establish and communicate team OKRs for the following quarter within my first 90 days – Agree with the team on max. 5 OKRs for the entire team for the following quarter. Share these OKRs – along with a related roadmap for the quarter – with the entire business by the end of my 90 day period at the latest.

Objective 2: To establish a product discipline within the wider technology function and communicate our role to the entire business within my first 90 days.

Key results:

  1. How does Product work with Technology, Design and Business Owners and why? – Agree with other ‘Heads Of’ and their respective teams on how to best integrate Product as a function, making sure the overall team structure reflects this. This agreement should be reached within 1 month from my starting, so that people have clarity about their roles and responsibilities.
  2. Communicate the role of product management, OKRs and team structure within my first 90 days – The goal is to make sure that everyone within the organisation know what the product team does and why. On a practical level, I want to make sure that people who sit outside of the product and tech team know who to turn to, when and why. I’ll be looking at the best way to (1) embed product managers within multi-disciplinary teams and (2) make these teams customer experience centric instead of just feature centric (see Peter Merholz’ great approach in Fig. 2 below).
  3. Talk to 100 people across the business in my first 90 days – The idea here is not to just have nice introductory chats across the business, but use these introductions to really learn about the direction of the company, views on products and customers. I might even ask the same questions in each conversation, almost like a mini research project to identify common themes (see Fig. 3 below). I will thus create a much better picture of key problems and opportunities to consider, which I can then feedback to senior management along with my related recommendations.
  4. Learn from at least 3 other product teams in my first 90 days – It will be good to learn from other product teams in different industries to compare notes on best practices, understand what worked well and what didn’t (and why).
  5. Shadow at least 10 different teams for at least 1 day in my first 90 days – In my experience, there’s hardly a better way to learn about a business, its products, stakeholders and challenges, than sitting with the different business teams. You can actively shadow your colleagues as they talk to customers for example (sitting with customer support is always a good one!). Equally, I’ve found that just sitting with a team on a regular and overhearing their conversations can give you valuable insights into to their worlds and their day-to-day challenges. This is something I strive to do on a continuous basis, well beyond my first 90 days, to make sure that I don’t develop tunnel vision.


Objective 3: To understand the current product portfolio and its fit with the needs of (target) users and against the market(s) the company is operating in.

Key results:

  1. Overarching business and product vision – What is the long-term vision for the business and why? How does this vision translate into a product vision? Is this vision well understood and shared across the business? I will work with the rest of the product team to work out how we can best drive this vision on a day-to-day basis and flesh it out so that it becomes a key driver for our products.
  2. Business strategy and business goals – Understanding the long and short business strategy is critical. Having an overarching vision is great, but it’s important to have context on how we’re looking to deliver on this vision. Which markets are we looking to target and why? Which customer segments are driving our vision and why? As a product person you might be closely involved in shaping the answers to these questions, but make sure you find out if you haven’t!
  3. Understand user, business, financial and market data – When looking at data, I’m planning on splitting my time spent on data in three different areas. Firstly, going through the company’s financials and forecasts to form a better picture of growth, profit margins and customer segments. I will then use this understanding to link back to the overall business goals – see above – and business strategy. Secondly, understanding our user segments, demographics and behavioural patterns will help me to better frame the problems or unmet needs to address. Thirdly, what does the overall market look like and how does it break down into specific customer segments? Who are our main competitors and what are their differentiators?
  4. Do a quick product (portfolio) audit – It will be interesting to really understand the value of the current value proposition and product portfolio. What problems do these products solve and for whom? Are there any customer needs or problems currently not solved by our products or services? If so, how do our (target) customers solve their problems or jobs without specific products or services in place?
  5. Talk to customers and partners – My goal is to speak to a good number of customers (B2C and B2BC) and partners in my first 90 days and beyond. This means developing good relationships with our sales and accounts people, who can help arrange short, problem interviews with customers. It will be my first foray into getting some real world feedback from our customers on, for example, how they currently use our products and why. I can then work out how to best engage with and learn from our (target) customers on an ongoing basis.
  6. Create a simple KANO model – I want to map our current products in a KANO model, identifying ‘hygiene factors’ and ‘delighters’ in order to get a better understanding of the competitive landscape (see Fig. 4 below).
  7. Explore competitive products and services, ‘mystery shopping’ – In my experience, mystery shopping is a good way to understand the competitive landscape and the differentiators of your own product or service. Using competitor products or observing customers using competitive products is a great way to learn more about user needs and your own product. How does your product or service compare to the competition? How does it benchmark?
  8. Study customer demographic and usage data, identify trends and patterns – I’ll definitely try to get my hands on whatever customer data I can get in order to learn more about customer segments and their behaviours. This will help me to understand trends and opportunities, identifying where we need to focus our product efforts and why.
  9. Identify which markets to target and why – Combining data on our products, our (target) customers and market needs to identify the best market(s) to target. This should also tie in nicely with the relevant strategic themes for the company, for example ‘internationalisation’, ‘partnerships’ and ‘retail’ and related business objectives.
  10. Use quantitative and qualitative data to create an experience map – Who are our users? Which jobs do they need to do and why? How do they feel about our products and services in relation to their jobs-to-be-done? Creating an experience map will help in understanding user behaviour in relation to our products and services. I’ve found the experience map exercise to be particularly helpful in relation to companies that don’t have a unified, shared view of their products or customers.
  11. Translate into a product strategy – Your initial product strategy can be fairly high level and you don’t have to lock yourself up in a dark room for 6 months to draft a plan. I believe it’s important to take your learnings and convert them into a plan which outlines how we can achieve critical business and customer goals, without getting too immersed in the detail. Instead, I tend to look at the high level milestones or building blocks that need to be in place to achieve specific business goals or solve customer problems. Melissa Perri recently wrote a really helpful article about how to create a product strategy, which I’ll definitely include in my toolkit (see Fig. 5 below).


Objective 4: To introduce the ‘minimum viable process’ necessary to address specific organisational or product related problems which impact product development or our bottom line.

Key results: 

  1. Is there a roadmap? Do we need one? – I know that some companies deliberately don’t have product roadmaps. Instead, they fully empower their product managers and engineers to liaise directly with customers and deliver against high-level strategic themes – companies like Hubspot are good examples in this respect. I, however, find having a product roadmap a very important tool in creating a product and customer centric culture across the entire business. A roadmap can be an incredibly helpful tool in conveying high level goals, milestones or themes to business stakeholders, teams and customers. I always make it clear that a product roadmap isn’t set in stone, but that it will give everyone in the business important context on what we’re looking to achieve and why.
  2. How do things get prioritised? – What criteria does the company use to add and prioritise things onto the roadmap. Are a product vision and roadmap in place that drive the roadmap? How do people assess new product opportunities? One the first things I’d like to do is to understand about any product or project milestones in flight or planned, and their underlying rationale.
  3. Product backlog, the next level down from the roadmap – Does the company have one product backlog or do the different teams have a number of backlogs that they work against? If so, what does the backlog look like, has it been ‘groomed’ and prioritised?
  4. How do things get shared across the business? (1) – Understand how people across the business know what’s going on from a product development and performance perspective. Often I see companies where product development is perceived to be a ‘black box’, with people being unclear about what gets developed (and why). I’ve also come across companies with a project management office that sends out status reports which are very task based and don’t necessarily provide a good update on the value we’re looking to create for customers or on tangible product progress. Like I mentioned in point 1. above, my preference is to have a high level product roadmap which is shared across the entire company (and ideally with customers as well). This acts as a simple but very effective example to convey why we’re building certain solutions or features and how we’re progressing against specific milestones or goals (see example in Fig. 6 below).
  5. How do things get shared across the business? (2) – Product review meetings, ‘all hands’ sessions or product retrospectives can also be a very effective in engaging with people across the business. The main reason why I’m always in favour of live demos over status reports is that people typically find it easier to see working software or a prototype instead of a written document. Even if you’re showing a non-finished article, you’ll at least be able to explain in person that a product or feature is still work in progress and what it is that you’re looking to learn (and why).

Fig. 1 – Sample OKRs to measure and review individual performance:

Instead of:

“To launch a new mobile app”

We will make the result more objective and measurable:

“To launch a mobile app for iOS and Android by the end of September ’16 and to achieve a 2% increase in mobile conversion by the end of November ’16.”

And make sure it’s aligned with key business objectives:

“To increase repeat purchase from 1.7 to 2.5 by 31 December ’16.”


Fig. 2 – Product managers embedded within multi-disciplinary product teams – Taken from:

Taken from:

Peter Merholz 1

Fig. 3 – Sample questions to ask during my first my introductory conversations in my first 90 days:

Generic questions to ask:

  • What is the overall vision of the company?
  • What are the key company goals or success criteria? What does success look like and why? Which one(s) are you working towards (how and why)?
  • How would you describe the company culture – what do you enjoy about working here, what could be improved?
  • Are you involved in developing new products or services? If so, how? If not, why not?
  • Who is your main customer? Is your customer internal or external? What do they care about and why?
  • What do you see as the main differentiator(s) of the business? Where do you see opportunities for the company or where are we lagging behind?
  • What are your observations with regard to the new products we launch to market and existing products that are already out there?
  • How do you currently collaborate with other disciplines within the company to deliver against company goals (e.g. working with traders, customer support or developers)

Questions about continuous improvement:

  • What does continuous improvement mean for our business and why?
  • Why is continuous improvement so important and what does success look like?
  • Have you got an example of where continuous improvement materially impacted the business’ bottom line? If so, how?
  • What kind of processes have you put in place to ensure continuous learning and improvement?
  • How do you go about instilling and maintaining a continuous improvement mindset across the wider business?

Questions about technology teams and leadership:

  • How do the developers currently interact with product managers, QA, UX as part of product development?
  • What is working well in that collaboration and what can be improved? Why?
  • What are the key roadmap goals or milestones for the coming quarter? How is success being measured?
  • What does the definition of “DONE” look like for the development team?
  • How and when do developers get involved in the planning process?
  • How do you currently structure your development team? For example, is it based on internal vs external, customer segments, specific problems, features or metrics?
  • (how) Do developers interact with customers?
  • Do you run a “dual track scrum” approach? If so, who gets involved in product and technical discovery?
  • How do you manage or mitigate technical risk?
  • What approach do you use with respect to testing? For example, do developers use TDD to test their code?
  • How do you balance fixing bugs, addressing technical debt with delivering business value, releasing new features?
  • How iteratively do the cross-discipline teams work? Is there a culture of continuous deployment?

Questions about customer experience and marketing:

  • How does marketing collaborate with product managers? When and how do marketeers get involved in the product lifecycle?
  • Who is responsible for developing a go-to market strategy? Who develops marketing strategies and related collateral?
  • Which customer profiles, segments and demographics are at the heart of our business strategy and why?
  • How do we go about reaching out to our target audience? Are there are specific areas that you are looking to optimise?
  • What does market growth look like and why? Are we looking at new – opposite or adjacent – markets?
  • What happens at the ‘initial insight’, ‘plan’ and ‘execute’ stages and why? It would be good to understand specific activities (e.g. story mapping, ‘jobs’, experience mapping, empathy mapping, etc.)

Fig. 4 – Create a simple KANO model – Taken from:



Fig. 5 – Product Strategy Canvas – Taken from:


Fig. 6 – Sample high level product roadmap – Taken from:



Related links for further learning:





Leave a comment

Posted by on July 19, 2016 in Product Management


Tags: , , , ,

Book review: Mobilized

I recently read “Mobilized” by SC Moatti, “an insider’s guide to the business and future of connected technology.” SC Moatti is a mobile veteran from Silicon Valley, having developed successful mobile products and services at the likes of Nokia, Facebook and Trulia. Moatti makes the book’s intentions clear in the first chapter: with businesses increasingly shifting their strategic focus to mobile, there’s a need to create a truly mobile culture and mindset within the business. To help companies become mobile first, Moatti introduces the “Mobile Formula” which contains the three rules for successful mobile products:

SC Moatti

SC Moatti’s “Mobile Formula”, the three rules of successful mobile products – Taken from:

The Body Rule – The best mobile products operate by beauty: Contrary to what one might expect, the beauty in mobile products isn’t about aesthetics, it’s about eliminating waste. ‘Efficiency’ is the keyword here and Moatti refers to the Birkhoff formula in this respect: M=O/C. In this formula, M is a measure of beauty, O of simplicity and C of complexity. Beauty will increase with simplicity and will decrease through complexity.

Measure simplicity through the “thumb test”: Ultimately, the best measure of simplicity is to create a product that’s easy to use by everyone. The so-called “thumb test” is a great way to test whether your product is easy to use. To pass the thumb test, a task should be easily completed by a user with a thumb of average size and without incidentally hitting an unrelated link, button or design element by mistake. Take a look at AnkiDroid for instance. The flash cards on AnkiDroid’s Android app make it easy to learn words in a different language, with clear buttons and calls to actions (see Fig. 1 below).


Fig. 1 – Screenshot of AnkiDroid – Taken from:

Even the “thumb test” will become redundant (eventually): With voice command software like Apple’s Siri ,GreenOwl’s service TrafficAlert and virtual reality all being hands free, the thumb test will eventually become a thing of the past (see Fig. 2 below). Moatti argues that the principle underpinning the thumb test will still apply: beauty on mobile means that all user interactions need to work effortlessly and efficiently.


Fig. 2 – Screenshot of TrafficAlert – Taken from:

The Spirit Rule – The best mobile products give us meaning: When describing ‘meaning’ in the context of mobile products, Moatti identifies ‘personalisation’ and ‘community’ as the two key factors that add meaning. One might argue that these two factors contradict each other, but Moatti makes compelling arguments for both. Firstly, ‘personalisation’ is all about the user feeling cared for, by giving the user total control of the mobile experience. Contrary to what one might think, recent research shows that mobile products create deeper bonds between users and their communities. For example, a study by Kyung-Gook Park at the University of Florida illustrates how mobile products make people feel more connected to those around them.

Building for meaning – Mobile products as extensions of our spirit: Moatti makes some great points about the use of internal and external filters to create mobile products with meaning. Internal filters, Moatti explains, can be as simple as our location or address book. These internal filters help in connecting users to their environment; using location or user based data to create a personalised experience for the user (see example in Fig. 3 below).


Fig. 3 – Personalisation through onboarding on Beats’ mobile streaming service – Taken from:

External filters come into play once it’s understood what users care about through internal filters. External filters allow the experience to be shared and enjoyed with other people. For example, a privacy policy is an external filter, in place to outline what a product can and cannot reveal about its users.

The Mind Rule – The best mobile products learn as we use them: The mind rule is the final component of Moatti’s Mobile Formula. Mobile products constantly adapting is of the essence here. This adaptation can happen either fast or slow. Messaging app WhatsApp is a good example of adapting fast. The team at WhatsApp have adopted a culture of ‘continuous learning’ where they learn from users and their behaviours on an ongoing basis, adding new features constantly. This is driven by a realisation that in order to keep up with the competition, they’ll need to adapt relentlessly.

In contrast, slow learning is all about breaking new ground, focusing on new users or launching new offerings. It basically comes down to taking one’s fast or iterative learnings to the next level; creating new mobile divisions to conquer a new target market or value proposition. Whereas an existing mobile product or business might not be the best place to explore new territory, due to a fear of alienating an existing customer base, a completely separate app might be a better place to do so.

Main learning point: “Mobilized” really made me think about how to approach the creation and improvement of mobile products. Most books on mobile products concentrate on design. The great thing about SC Moatti’s book is that it focuses on the mobile user instead, and provides great insights on how to best create a great user experience.


Related links for further learning:


Tags: , , , ,

My product management toolkit (11): assessing the market

As a product person it’s extremely important to keep a finger on the market pulse at all times. It can be very easy to get locked into a tunnel vision where you’re so focused on developing your product that you lose sight of market needs or what your competition are doing.

Let’s be clear: this doesn’t mean that your product or company has to become ‘me too’, blindly following what the competition is doing. Equally, it doesn’t mean that you shouldn’t develop a feature if another company has already done it. Understanding your competitive landscape and your positioning in it urges you to constantly reflect on positioning, user needs, customer segments and differentiators.

Tool 11 – Assessing the market

As with anything, there are a number of ways to look at the market your company or product operates in. I’m personally not wedded to a single technique; whatever approach or visualisation gives you the best picture of your market and the players – competitors or customers – in it. As part of my toolkit, there are a number of simple techniques I often use to paint this picture: the KANO model, the Business Model Canvas and the Value Proposition.

KANO – Distinguishing between “Basic needs” and “Delighters”


Taken from:

I find the KANO model a great way to look at the market through the lens of a customer. Which needs are considered to be “basic needs” and why? What are the “delighters” that will give your product an edge? It’s fairly easy to learn from your (target) customers about where they perceive your product or features to sit and learn how this positioning compares to your competitors.

Business Model Canvas


Taken from:

Alex Osterwalder’s Business Model Canvas lets you look at your product more holistically, taking into account important factors such as revenue streams and customer segments. I’ve often used the Business Model Canvas as a starting point for a group exercise where we filled in the canvas together or where I provided the group with ‘my canvas’ and asked them to critique.

Value Proposition Canvas


Taken from:

I see Alex Osterwalder’s Value Proposition Canvas as a great extension of the Business Model Canvas, the empathy map and the jobs-to-be-done framework. It’s a really useful tool for delving into the (assumed) problems that you’re looking to solve through your product or service, understanding the value you’re creating for your customers.

Related links for further learning:




My product management toolkit (10): Jobs-To-Be-Done

How does one combat what I call “featuritis”? This innate need among most of us to come up with new features or projects all the time without taking a step back to figure out the customer problem worth solving. I recently came across a company where they’d created so many features and products that they’d lost track of what constituted a “product” in the first place.

In both cases the “jobs-to-be-done” framework can help massively in systematically capturing user needs and translating these into opportunities and solutions. The whole point behind the jobs-to-be-done framework is putting customer needs at the fore, throughout the product lifecycle (see a great visualisation of this principle below).

Tool 10 – Jobs-To-Be Done

Tony Ulwick

Taken from: Tony Ulwick at Business of Software Conference 2014 –

Why and when is it important to use the “jobs-to-be-done” framework?

Before you delve into creating features or solving problems, I strongly recommend looking into the “customer jobs” you’re looking to solve in the first place:

  • What job is the customer looking to get done and why?
  • How is the customer currently getting this job done?
  • What jobs are customers not doing and why?

Strategic thinker Tony Ulwick identifies three validating questions to help map the steps customers take to accomplish a specific outcome:

  • Defining the execution step: what are the most central tasks that must be accomplished in getting the job done?
  • Defining pre-execution steps: what must happen before the core execution step to ensure the job is successfully carried out?
  • Defining post-execution steps: what must happen after the core execution step to ensure the job is successfully carried out?

Answering these validating questions will give you the necessary context to apply the actual jobs-to-be-done-framework.

The jobs-to-be-done framework outlines the eight steps that all jobs have in common:

  • Step 1 – Define: Customers determine their goals and plan their resources.
  • Step 2 – Locate: Customers gather items and information needed to do the job.
  • Step 3 – Prepare: Set up the environment for the customer to do their job.
  • Step 4 – Confirm: Verify that customers are ready to perform the job.
  • Step 5 – Execute: Customers carry out the job without any problems or delays.
  • Step 6 – Monitor: Assess whether the job is being successfully executed.
  • Step 7 – Modify: Make alterations to improve execution.
  • Step 8 – Conclude: Finish the job or prepare to repeat it.

One of the things I really like about the jobs-to-be-done framework is the focus on user outcomes, the “so what” element of the typical ‘job statement’:


Standard format of a job statement – Taken from:

What are the benefits of the jobs-to-be-done framework? – Where do I start!? The main thing for me is that it helps me to unlock the value for the customer. Bob Moesta, who has done a lot of work around the jobs-to-be-done framework, talks about the “mechanisms of value” in this respect. What are the things that caused someone to buy a product or a service? What are people doing or not doing (and why)? I’ve listed some additional benefits in Figure 2 below.

Main learning point: There are two key reason why I like using the jobs-to-be-done framework. Firstly, because of its focus on value for the user. Secondly, because of its emphasis on outcomes. In my experience, thinking about jobs and outcomes really helps to focus the mind!


Fig. 1 – Fictitious examples of 8 steps of the jobs-to-be-done framework

Example of “Define” (Step 1) – I need to find a quick way to understand my monthly mobile phone bill and how to spend less on mobile phone bills. Perhaps looking at the top line items on my bill can help in figuring this out.

How can a company help customers in this example? – Create a real-time version online of a customer’s mobile phone where they can quickly and easily scan their mobile phone bill breakdown.

Example of “Locate” (Step 2) – I need a quick view of how much I’ve spent this month on text messages and international calls.

How can a company help customers in this example? – Colour code those cost ‘components’ of the mobile phone bill where the customer is (at the risk) of exceeding what’s covered in her contractual package with the mobile provider.

Example of “Prepare” (Step 3) – When I am looking at my billing information I need to know about the specific phone numbers I’ve rung or texted.

How can a company help customers in this example? – By stripping out all ‘non monetary info’ from the bill (i.e. removing all data related to phone numbers).

Example of “Confirm” (Step 4) – I would like to get a reminder to look at my mobile phone usage before an invoice is sent out by the mobile phone provider.

How can a company help customers in this example? – Send customers a push notification 7 days before the monthly invoice is sent out to remind the customer to check usage and make any package changes, including a link to the real-time data.

Example of “Execute” (Step 5) – The billing information that I am looking at needs to be as up to date as possible, it’s no good to me if the data is more than a day out.

How can a company help customers in this example? – Ensure that there are no lags in the data provided, maintaining optimal performance.

Example of “Monitor” (Step 6) – I expect the mobile phone provider to keep tabs on whether I’m checking my billing information, so that I when I contact them to enquire about charges they can see exactly which information I’ve accessed.

How can a company help customers in this example? – Putting analytics in place – both for desktop and mobile – to monitor data usage on an ongoing basis.

Example of “Modify” (Step 7) – Personalise the way in which billing is presented to users, based on their previous viewing behaviours or enquiries.

How can a company help customers in this example? – By personalising the data presented to the customer, the mobile phone provider will save the customer from having to wade through lots of data or having to customise data themselves.

Example of “Conclude” (Step 8) – I’ve seen my real-time billing info and will now log out.

How can a company help customers in this example? – Provide the customer with appropriate calls to action once they’ve viewed their billing information, for example contacting customer service.

Fig. 2 – Benefits of using the jobs-to-be-done framework:

  1. Helps to understand value for the customer
  2. Identify the progress users are (or aren’t) making towards their desired job outcomes – see visual below
  3. Focuses people on outcomes and needs instead of solutions
  4. Takes into account user context
  5. Helps to to concentrate user research on what users actually do instead of what they say they do
  6. Enables you to distinguish between the ‘main job to be done’ and ‘related jobs to be done’ – see visual below – and to prioritise accordingly


Progress Making Forces diagram – Taken from:

Jobs main - related

Main jobs to be done vs related jobs to be done – Taken from:

Related links for further learning:


Tags: , ,

Midpoint: peer-to-peer foreign exchange

I’m increasingly getting the sense that everything is possible in FinTech, at least from a peer-to-peer (‘P2P’) perspective. For example, marketplace lenders like Funding Circle and Zopa are all based on a P2P model whereby borrowers and lenders can transact directly.

I recently learned more about P2P foreign exchange services by listening to an episode of the London Fintech Podcast which featured John Booth, Co-Founder and Director of Midpoint. Midpoint is a London based P2P foreign exchange firm which facilitates “international money transfers at unbeatable rates.”

These are the main things I learned from listening to John Booth from Midpoint:

  1. Intermediation in peer-to-peer money transfers? – In the podcast, both John Booth and Mike Baliman, the podcast host, made the point that P2P money transfers still require a degree of intermediation, either by a bank or a P2P currency matching platform like Midpoint. The point was made that ‘opposite transactions’ – where the buyers and seller match each other immediately – almost never happen. You’re still most likely to be needing a middle man to match the relevant currencies (see the Kantox example in Figure 1 below).
  2. Waiting for a match to happen – Midpoint guarantee that the execution of a transfer will take place within 24 hours. John Booth made the point that P2P forex transactions sometimes take time to match, in spite of the simultaneous buying and selling that takes place through its platform. As a result, you won’t know upfront what rate you’ll pay for the trade. Booth made the point that there’s always going to be a need for a “fallback deal with the market” to ensure trade gets closed out in a reasonable timeframe.
  3. White label solutions – Like many FinTech businesses, Midpoint has kicked off some successful white label solutions and partnerships with the likes of accounting software provider Xero. They thus provide a seamless experience for private clients and SMEs wanting to pay their foreign invoices at the best possible exchange rate (see Fig. 2 below).

Main learning point: Listening to Mike Baliman and John Booth talking about peer to peer foreign exchange made me realise that it’s not entirely P2P, at least not on the consumer side. There’s still a need for some form of an intermediary to match currencies and platforms like Midpoint might still need to fall back upon ‘the market’ to ensure that transactions are executed upon within a reasonable timeframe.


Fig. 1 – Visual representation of Kantox’ intermediary role in facilitating peer-to-peer money transfers between companies and the wholesale FX market – Taken from:

Screen Shot 2016-05-15 at 16.43.33

Fig. 2 – Midpoint and Xero, facilitating payment of foreign invoices – Taken from:

Related links for further learning:



Tags: , , ,


Get every new post delivered to your Inbox.

Join 1,027 other followers