Leadership / Feedback

This is a complicated post to write. How to give constructive feedback. From my side, feedback is always welcome, not only at work but in life in general.

When I was a kiddo, I worked in Spain for a year and a half and never got any feedback, nothing matters in here.

When I got to Ireland, after two weeks, I received a “good stuff” because of developing a proxy pattern in two days and I felt really good, just because my work had been gratituted. I remember going home with this song (I have no clue why):

There are three different types of feedback:

  • Negative: You need to understand how the person is, feels in the company and why they are performing badly… The most important thing is that they don’t feel attacked. Both people need to understand why is happening and get to a point of construstive feedback. Never say like it happens in here: you are useless.
  • Neutral: Keep doing what you are doing, this is working and if you put a bit more effort, and you can, we can progress with your career, blablaba…
  • Positive: This is the most important one but the most complicated one. Usually, the person that is performing really good already knows it, but it’s really important to tell them they’re doing well. This will encourage them to keep performing as they are doing, feel important in the company and possibly get more money and promoted.

Exceptions:

  • You cannot treat everyone the same way. Imagine you are the coach of FCB. Would you treat the same way Messi for a bad match as you would treat Semedo? Guardiola explained it very well (with the help of Estiarte). When you have a real talented person, take care of them. No matter if they fail because they got drunk the night before, let them play, allow them to do whatever they want ‘cause they are going to do stuff that the rest of the staff cannot. It will be beneficial for your company no matter what.
  • Take care of people not sure about themselves. Try to get the best of them giving them the confidence they need. Believe me, if you give confidence and responsibility to someone that is not sure about their skills, you’ll be surprised on what they can give to the company.
  • 1-1: It is imperative to have a one to one every 1-2 weeks in order to understand how people feel and be able to give them the feedback they need in order to get the potential they have.
  • Go for beers with them. Having a beer with a colleague in an Irish pub is the best solution for everything.

Ander Telleria

Anuncios

Business Model Canvas

Once upon a time, we lived in a better world, where for presenting a business model, you had to write a document of 50, 60 pages… just joking, it was hell… At some point, a guy called Alexander Osterwalder created the business model canvas.

This is quite related to the https://myagileandproductboard.wordpress.com/2019/03/17/elevator-pitch/ I wrote about some weeks ago. As a client, you don’t need to read 60 pages of padding to understand what the business model you are trying to sell is. Someone in 5 minutes can explain it to you using a single canvas.

I was doing one of those some days ago and I remembered to write about it. As my one is protected by an NDA, I will use an example, as always: iPod from Apple changed the whole industry of music market with this new business model (image taken from stfalcon.com).

Ostelwalder thought about it as a brain. The right part of it is the creative one, and the left part of it is the operational/logical one. Right (what to do and offer), left (how to do it). It has to be presented in the following way:

  1. Customer Segment (what users we are aiming for)
  2. Value Proposition (what we offer to the user)
  3. Customer Relationships (how we interact with the users to get feedback, sell, offer, etc…)
  4. Channels (through what channel we are offering our value proposition)
  5. Revenue Streams (how we are going to get money from this business)

(Until here we have the proposition, now we are going for how to do it).

6. Key Activities (what we need to do for make it real)

7. Key Resources (what resources we need for this to happen)

8. Partners (what partners we can deal with so that both of us get befenit from)

9. Costs (what are the costs of making it possible (this needs to be aligned with the revenue streams).

By doing this, you can present it in 5 minutes and make it fun, but most important, you need to think on the 9 points of what a business model has to focus on.

Ander Telleria

Peter’s Principle

Please raise your hand people that have met a CEO that was the creator of a product and became CEO just because of that and has not an idea on how to run a company.

Please raise your hand people that have had a boss that hadn’t had a clue on how to perform their job, drive and lead teams.

Please raise your hand people that have met someone stressed because they were not ready to perform their job properly.

This what Peter’s Principle says (it happens EVERYWHERE): people in the same company getting promoted because they are doing their job really well, but when they have more responsibility, they are just not prepared and get to the no return point: incompetence.

So, my advice… if you are being promoted, keep learning, read, go to summits, know people of your new status, go back to college, but don’t think that because you were good at your previous job, you are ready for taking more responsibility.

Ander Telleria

Elevator Pitch

When someone asks you for an elevator pitch (you need to explain your business model in the time the elevator gets from one flat to another, usually 20 seconds…) You should be ready to tell it in that frame of time. For that, as for everything, we have frameworks.

For (customer segment) who have the problem of …, our product is a …. application that provides them with …. (value proposition). We have … (our company’s best assets). We need to make the most of it.

As always, we’ll show it with an easy example

For american teens who have the problem of sexting without knowing where the pics will end up, our product is a mobile application that erases the picture after it has been seen. We have the proper technology and engineering team to make it possible. Look!

This company is worth over a billion now, guess what it is.

You’re welcome padawans.

Ander Telleria

Product Strategy / Roadmapping


As a Product Owner, you need to base your strategy in 4 different pillars.

  1. Market Investigation: you need to understand the market in order to start the workshops. I’ll talk about it later on. I could put an example of a spanish company called Tuenti (Facebook bis) that was bought by Telefonica, researched the market, understood that they had nothing to do against Facebook and pivoted from a social network to a low cost phone company (It works). They have even pivoted to do dance sessions (imagine, from a social network to a party . Market research and pivot. But I like to write more analogies far from the typical SaaS methodologies. i.e. Nintendo: They were trying to fight Sony and Microsoft with their 64 bits consoles and failed resoundingly… What did they do? Research the market, understand what was needed and they launched Wii.

According to VGChartz latest sales data the PlayStation 3 has sold 77,313,472 units to date, while the Xbox 360 has sold 77,311,669 units… The Wii, the bestselling home console for the seventh generation, is 22.35 million units ahead of the PlayStation 3 and Xbox 360 (source Wikipedia). Even if it had less than half engineering, computing power, less exclusive games, etc… than the other two consoles…they understood the market and they won.

2. Potential Client Requirements: I’ll be straight away in this one. You talk to your client and ask them why they want what they want (Henry Ford to potential clients: “What do you need?” “Faster horses”… He invented the car).

3. Feedback: I usually go get feedback after 1,3 and 6 months to the clients. From there, I understand what worked and what didn’t.

4. Analytics: As you can remember, Dr. House always said that patients lie. Clients lie as well but analytics don’t. It’s data and we are fortunate to see what users do and what they don’t.

Once you have all this data, you can apply Robert Phaal‘s framework to roadmapping


It is really important to have all the stakeholders in all the workshops. We are a team (don’t forget that), we want the product to go ahead no matter what, so we need to become a nut and go ahead. Usually what I do is expose the ideas I got in the first four points and give them post its, so that they can expose their ideas on a wall. After that, we debate, discuss, even hard words, but in the end…. product rules and the different stakeholders get together so we can succeed.

Once all the stakeholders are onboard (and if you are a real leader, they’ll be), we go to what is needed to achieve what we have decided to do (first sixth months).

When someone asks you to create a roadmap for two years, ask him/her to call David Copperfield, cause it’s impossible to know what’s going to happen…

Ander Telleria

MVP (Waterfall vs Agile)

Some years ago, when I would listen to MVP word I would have thought on Kevin Durant or Lebron James. Suddenly, a guy called Eric Ries created this same term but with a completely different meaning: Minimum Viable Product.

An MVP is the minimum product that is valuable for a user to perform their work properly. Then we’ll go adding stuff that the client understands that needs after using the MVP.

Here is a clear example between Agile and Waterfall:

Imagine you are an architect and a client with four kids asks to you to create a house with 5 bedrooms, three bathrooms, a kitchen, leaving room, a swiming pool for the kids and a gym, etc… (the typical BRD (Business Requirements Document). You, as an architect, do all the maths and estimations and tell the client that the project will take 3 years). Now imagine that you finish your perfect project within the three years. But… client has changed in those three years. He has divorced so does not need so many bedrooms, he does not want a pool anymore as the climate has changed and the kids don’t live with him anymore, the gym is something he does not care about at this moment… what a fail right? Market changes quickly and waterfall does not allow you to adapt to it, so you will spend a lot of money on stuff you don’t need/want.

Now imagine you want to apply Agile and tell the client: I’ll give you an MVP in three months (one bedroom, one bathroom, leaving room and the kitchen). The least you need to live a perfect life but not with all the grace notes. And once you are living there, we will iterate to adapt the product I am building for you to your life.

Sometimes I have debates with other Agile coaches and they say that the MVP can fail. NO! If it fails, you don’t want to be there. Why would I want to live (use your product) in a house without windows??

MVP means building and delivering 100% of the 30% of the product (for example), not the 30% of 100% of the product. Think about it…

Ander Telleria

User STORY (yes, STORY!!!)

Everytime I join a new company, I get still shocked reading the user stories some Product Owner write. Just a line, with technical requirements, and nothing else. Don’t we understand why it’s called a story?

Example of what I’ve been seeing lately:

  • We need that the user can log in to the application.

What the hell is that? How should it be written (let’s take into consideration that my mum needs to understand it, and when I say my mum, i mean anyone)? As its name says, you need to write a story:

  1. The user accesses http://www.myagileandproductboard.com.
  2. There are two forms that the user needs to input data in:
  3. Username.
  4. Password.
  5. The user enters both fields and clicks on Login.
  6. The data is correct and the user gets navigated into the landing page of the blog.

Exceptions:

  • The data entered is not correct.
  • An error message is displayed saying that the username or the password are wrong (for security reasons we don’t say what’s wrong).

What developer would not understand this user story? Writing user stories in this way facilitates the Grooming sessions (where the magic happens, as sometimes devs know more than the owner about the product and user stories can be edited and adapted to the software’s carachteristics). And better yet, UAT people will be able to test them properly.

A user story needs to have the following charasteristics:

  1. Independent (this is not posible when you are creating a greenfield product but when the product is on the road, it has to be independent).
  2. Negotiable: you need to be able to negotiate it with all the stakeholders of the product.
  3. Valuable: It has to give value to the client/customer. Technical backlog ARE NOT user stories.
  4. Estimatable: They have to be estimated as you need to tell the client what are you giving them and when. #noEstimates sounds good, but it’s unrealistic.
  5. Short: It has to be small. In order to get to continuous delivery, a user story should not take more than three days.
  6. Testable: It has to be so clear than the QA and UAT team can test it without asking what needs to happen.

If you take the first letter of each point, you get why user stories need to be written this way: INVEST (time and effort).

Ander Telleria