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 can not. 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

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 stakeholder, 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 following this simple framework, you can present a thorough business model in 5 minutes and make it fun. But most importantly, you need to think on the 9 points of what a business model has to focus on. Give it a try…

Ander Telleria

Peter’s Principle

Please raise your hand if you have met a CEO that was the creator of a product and became CEO just because of it. He has no a idea on how to run a company, right?

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

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

This is what Peter’s Principle is about (it happens EVERYWHERE): people working at the same company for a long time getting promoted because they are doing their job really well. Now, when they get more responsibilities, they are just not prepared. Suddenly, they find themselves at the «no return point»: incompetence.

So, my advice… if you get promoted… keep learning, read, go to summits, know people at your new level of responsibility, go back to college… whatever!! 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 (channel) …. 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 listened to the word MVP, I would have thought of Michael Jordan 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 in order to satisfy their needs properly. That’s all.

Let’s see a clear example between an MVP and what we used in the past, a BRD (Agile vs 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, a leaving room, a swiming pool for the kids and a gym because, hey, it’s cool to have a gym at home (the typical Business Requirements Document). You, as an architect, do all the maths and estimations and tell the client that the project will take 3 years and will cost $1M. All good so far.

Now imagine that you finish your perfect project but instead of 3 years, it took 4. The land where the property was built was harder than expected, some materials didn’t arrive on time, people on the construction team left during the project and it was complicated to replace them, there was a hurricane last year that destroyed part of the building. Also the cost has increased the budgeted $1M to $1,4M. Shit happens…

Anyway! You’re so happy with the end of it and how amazing it looks that can’t wait to meet your client and show it to him…

You set up the meeting with him so he can see it but… Surprise! His life has changed during these three years. He has divorced so he does not need so many bedrooms as the kids don’t live with him anymore, he does not want a pool as San Francisco was sunny on the postcards but in reality is cold and windy, the gym is something he does not care about at this moment… Shit! The project is no longer valuable for him and you have wasted his money and your time building something that was not required.

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) and for $400K. The least sized property 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. San Francisco is cold? Why would we build a swimming pool?

It doesn’t look you’re going to have 4 kids so let’s not build so many bedrooms. Instead, I’ve noticed that you usually meet with your friends every sunday to watch the NBA match. Why don’t we build a barbecue place in the garage with a TV, a pool table and a bar?

Conclusion: you, as the arquitect, will deliver the product earlier and with a lower cost. The client will wait less time to fulfill his need and will not waste money in stuff he does not really want.

Think about it…

Ander Telleria

User STORY (yes, STORY!!!)

Everytime I join a new company, I still get shocked reading the user stories they are using. In general, they’re just a line or two with little explanation. Don’t we still understand why they’re called a story?

Example of what I’ve been seeing lately:

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

What is that? As a developer, if I get this I would shocked. If I was someone from marketing, sales or finance I would not care at all about it.

How should it be written, then? For starters, let’s take into consideration that my nephew needs to understand it, and when I say my nephew, 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 it is when the product is on the road).
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 anything about it.

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

Product Manager vs Product Owner

It happens in every interview. «What is the difference between a Product Manager and a Product Owner». I am not sure why this question is asked in every meeting but well, I’m lucky enough that I talked about it with Jeff Sutherland (Co-Creator of Scrum) in a workshop in Dublin to know the answer (what low number of people know).

People believe that a Product Manager is a fat guy sitting down in an office and smoking a cigar while taking decisions that people with lower positions (like a Product Owner) will make happen. This is not true.

A Product Owner is a broader role than a Product Manager. They have all the responsibilities of a Product Manager plus they work more closely with the engineering team (50% more, to be clear). That’s why Scrum created another role called product marketer (which can be done by the product owner as well), but just in case someone would need to work more than 7h30m per day.

Actually, it’s just a name. A Product Manager does not manage anyone, they own the product. That’s why Jeff wanted to get rid off the manager word.

That’s all, so when someone asks you what is the difference, just have a laugh.

Ander Telleria

What (the hell) is Agile?

I remember when I joined the first company (back in 2010) where Agile was being applied. I knew one of the questions in the interview would be: “Do you have experience in Agile?” “What is Agile?” “How do you apply Agile?” Some days before I started investigating what the hell was that thing. I wasn’t able to understand it. Wikipedia, articles, blogs… I read everything I could…nothing, everybody was talking about stand ups (I’ll do a post regarding methodologies in the near future). Obviously my answer was ridiculous… What a shame. Fortunately I got the job (I was a developer at that time) and I started to understand what was that crazy idea of Agile.

The first thing that I have to say about Agile is that you need to understand what it means (the name tells you what it is!). Forget about Scrum, Kanban, Lean, whatever…. These are just methodologies to achive being Agile.

Forget about the Agile Manifesto (by now). Just get a clear idea on what Agile means.

It is an abstract concept. You need to look at the market and react with agility to its changes/feedback. That’s all, it can’t be easier.

In order to get here, obviously, you need methodologies, which we will review in future posts.

I’ll put a couple of easy examples so that it gets crystal clear.

– When I do workshops, I usually have a spounge ball with me in the first hour of the training. There is always someone that is with their laptop working and not paying attention. What I do, is to throw them the ball. I am the market, you are not looking at me, your product (you) cannot react because you are not paying attention so you will fail.

– Whatsapp introduced a new change in the last months that says “forwarded” when you forward a message. But they’re not stupid, they kept looking at the market and a couple of weeks after, they removed the “forwarded” word if you are the creator of the message. Try it and forward one message you wrote and send it. You won’t see it. Hint: they were looking at the market, listening to feedback (Basically, senders were sending pics to many people at the same time and pretending it was an exclusive message for the receipt… ha!) and changed it rapidly: This means being agile.

This happens all the time not only with software applications. As Agile is an abstract idea, any company can apply it. The company that applies the best Agile behavior, in my opinion, is Ryanair. They try everything and get feedback. If it does not work, they change it quickly, if it works, they keep it. Easy, isn’t it?

Ander Telleria