CxO: You are Your Organisation's Product Manager

Thank you. This is my second time in India, and I am amazed by how amazing the food is, even at a hotel buffet. Okay, I am going to go over here. So, the first thing I want to explain is the title of my talk. It says, "Hey, CXO, you are your organization's product manager now." All of us here are either CXOs, aspire to be CXOs, work with CXOs, or are part of a team, and we are all here because we are trying to make a change; we are all here because we are trying to make an impact. We are working with all these people who are trying to make that impact, and this is what a product manager does: a product manager looks at a problem, looks at his or her resources, and thinks about how to create that impact. So, my talk will be about how we use that lens, that product lens, to look at how we develop our organization.

First things first, transformation is hard. If you think it is not hard, I would like to invite you up here, because I want to learn from you. I have done this a few times now, and it just gets harder and harder, because expectations change. So, when I started with making change, this is how I was taught in my MBA: "This is our current state; this is our target state; let us put together a plan and the resources, and let us just execute that plan, and we will be in this better, brighter future." Now, what does that sound like? I do not know about you, but it sounds a lot like waterfall, and we know that waterfall projects, IT projects, software projects, fail. So, why do we use those same methods in making change? That was the first thing I learned: using that way does not really lead to the successes I want, because things are unstable, there is uncertainty, a whole host of reasons. So, what did I try next? Since we were using Scrum and Kanban and agile methods, let us iterate our way to a better future. So, we were using sprints: plan, execute, retro, adjust. I have been doing it for about a year and a half now. It still does not go to plan, because, unfortunately, people are weird. Humans are weird; humans are uncertain; they are unstable. Basically, any kind of plan will go awry really quickly. This is where I find it really difficult to make change, because the change starts taking on a life of its own. Whatever we have planned will not stay the plan; whatever we think will happen will probably not happen; and things that are uncertain probably will happen, because humans are uncertain. There is a lot of uncertainty, and we are all in a very complex system. So, this got me to think about what I could do.

First, before I start, let me give you some context about the environment that we are in. So, I am from SEEK Asia. We are Southeast Asia and Hong Kong's largest job marketplace. So, if you were to look for a job in Southeast Asia or Hong Kong, you would come to one of our brands: SEEK, JobsDB, or JobStreet. But what matters today is the environment that I am working in. So, we have four engineering centers, we are about 200-plus strong across these four centers, and we are trying to change ourselves to be more competitive. We were largely traditional, but then we were competing against the likes of Google and Facebook and Indeed.com, so we had to be a lot better. This is the story so far.

In the beginning, it was a merger of two companies, very fierce competitors, merging together under the SEEK umbrella, and largely without direction. We did not know where we were going; we were acquired; we did not know where we were going. So, the first thing we did was to build a solid foundation, to have a solid direction of where we were heading. We did things like restructuring; we put people into teams: squads, mission teams, where each team had a purpose. We hired scrum masters, product managers, designers, and put them into customer-facing teams, so that at least they knew who their customers were. Then we aligned the organization using objectives and key results, so that each team knew who their customers were and how they could actually help the lives of their customers. We invested in learning and development; we invested in managers and things of the like. Then we realized that this still was not good enough, because while we had the structure, we were still not moving fast enough. That is today's story: how do we accelerate that change?

One of the things that is really popular today is startups: your Ubers, your Facebooks, your Indeeds, your Googles. Everybody wants to be like that, but not every company is a new digital company. Most companies have been around for a really long time. So, how does a company become like that? You will see things like a big existing company, like a bank or a telco, will create a digital innovation hub, or internal startup, or internal accelerator. But what is that, really? In my experience, working in a startup is about three things: a combination of design thinking (or UX, depending on which school of thought you are from), product management, and this thing called agile. So, while thinking about this, it raised a question in my mind: what works for product development and startups, will it work for organizational development? So, this was the question I had. Why did I start?

Well, when I looked at it, I googled around and I found that Gartner has this interesting model. I do not know why they just call it the "Gartner model," but it attempts to integrate these three things together: design thinking, lean startup, and agile. Basically, design thinking is about finding the problem, lean startup is about experimenting to find a solution, and agile is about delivering and scaling that up. So, this is very simplistic, but to me, it was a way of integrating the different schools of thought into one holistic view. So, I am going to start there.

What is the first thing to do? I will just follow the model. Within SEEK Asia, we have multiple products: the web, all the mobile products. So, we were familiar with these tools already. We were using things like the double diamond, the experiment board, we were doing A/B testing, we were doing design thinking, we had the business model canvas, we were using all this. Internally, we had the experience in building it with the product. I wanted to explore whether we could apply those skills in a different avenue. So, one of the things that got me thinking about whether this could be applied is based on my worldview, which I will share with you. It is a simple worldview: every business exists to be successful. If you are for-profit, then you exist to create value and profit for shareholders, directors, employees. The big money, essentially. If you are an NGO, then it is about creating impact. But every organization exists to make a difference. So, how does a business do that? Well, every business has a customer, because the customer buys your service, buys your goods, and in exchange they give you money, or whatever it is that you want from them. But how do we satisfy our customers today? In the old days, you know, with Henry Ford, he said, "You can have a car in any color you want, as long as it is black." But today is a completely different world, because the customer is king, and the customer is fickle. So, the way to keep a customer and make them loyal and have them return to you is to provide them with a fantastic product experience. So, that is why we are thinking about product now. Product, product, product. Everything is about the product, because the product provides the experience that keeps your customers loyal to you. Then this is the question: how do I, as an organization, as a business, create that fantastic product experience? We need people. The answer is people. It is all of you and the other people you work with. So, this is my worldview: for a business to be successful, they have to please and satisfy their customers through a fantastic product experience, as developed by people in the organization. So, if I wanted to be successful as a business, to build a fantastic product, I had to satisfy my people and build that organization. So, this leads me to my goal now, after we created a foundation: to accelerate. That is, the product is our learning organization: learn about customers, learn how to satisfy our customers, and learn how to be better.

Step one. So, I was doing this for the first time. I am from a technology background, but I have had experience in multiple places, so I just followed the Gartner model and had to learn what that is. So, the first thing to do is, what was my business model? What am I building? Now, traditionally, an organization or a company would think of it as, "I am demanding talent, so I will buy talent from the market." Pay money for time. But one of the issues that technology companies face today is that good talent is extremely hard to find, and harder to keep. This was my problem. It was very difficult to find talent; talent was scarce; every other company was looking for talent; and once we got them, they might leave really quickly. Engagement was an issue. So, I looked at it and I decided to flip that. What if the customer was not the company, but the customer was the talent, the employees, and then on the other side is the company? So, what does the company have to offer? On the supply side, pay, salary, opportunity for learning and growth and development, opportunity to pursue really challenging problems. Then on the demand side, it is people with the capability to grow and solve those challenges and be creative and be innovative. But good people have the ability to pick almost anywhere they want to work. So, I flipped that on its head: supply side is the organization, demand side is talent. So, that is my business model, and that is my business canvas. As part of my business canvas, I developed it... Well, I needed to hire people, so what I did was I actually went to my boss, the CIO and the CPO, and begged them for money to hire a contractor to try this crazy experiment. So, I approached it like an internal startup. I looked for seed funding; I got a contractor for three months; and I had some KPIs, which I met, and managed to convert that person to full-time. So, the second step here is to empathize with our customer. So, the customer in this case is talent. So, with my new hire, we interviewed our employees as though they were customers, and we developed personas. So, you may be familiar with personas from a product sense; this is personas for our people. So, from there, we created segments. So, within our company now, we have about eight personas, and I will share with you one of them. These are real things that we use internally. So, we have a guy called Wiseman Larry. Wiseman Larry is a guy, or a girl, who has been with the company for years, very loyal, developed existing products. Unfortunately, Larry's skill set may have slipped a bit. Maybe he has been using PHP for a really long time, or .NET, or Java, but now the trend is AWS and React and mobile and all these different things. So, Larry, while he knows the existing systems, he knows the history of the company, his skill set may no longer be relevant. So, we understand Larry; he has some frustrations. He cannot move forward with his skills, even though he is senior, because all these young guys have all these new skills. He may not be able to contribute as much with all the new tech stuff, so he feels really frustrated. But he is also critical to keeping the existing platforms running. So, he is stuck. So, what we did was, we did all these interviews, we generalized them into personas, and what we got from that is step three: what are our customers' pain points? So, we identified six of them, of which I will share three. The first one is, "I need more support to grow my capabilities." For instance, "I do not feel heard when I share things." "I feel I do not matter." "I do not know where I am heading." So, these issues, while they are relevant to my company, I do not want to touch them too much, because the process that we took was, we did not assume what challenges our people were facing. We went to them, we talked with them, we identified their pain points, and then we solved their pain points. This is what we came up with. So, how do we go about solving our customers' problems? We are thinking design thinking, or a systems approach. So, much like a product does not exist in isolation, even an iPhone in your pocket, or a smartphone in your pocket, does not exist in isolation. You have your app store ecosystem, you have your ad ecosystem; all these things play into the modern product ecosystem. So, what was my ecosystem internally, if I wanted to develop this organization? Well, there are basically four or five things. At the center of it is my customer, which is the employee, my talent, and then you have traditional artifacts like performance management and performance appraisal; that is from HR. Then we have career management: how do I get promoted, what is my career path, how do I grow within this company? Then we are also building communities of practice here, supported learning: how do people who are interested in the same thing learn and grow together? Then the last bit, which is probably my part, the product I am developing, is a learning marketplace. I am using a learning marketplace to incentivize learning, to make learning and growth easy. But basically, that is my core product, and the rest of it is within the ecosystem at SEEK Asia. From there, we have to execute, but we are not going to create a plan that we just execute, you know, ABCDE. We want to experiment. So, the heart of lean startup and finding solution or product-market fit, in this case solution-market fit, is to really experiment. So, instead of having a work backlog, we created a hypothesis backlog. One of the first hypotheses is, "We believe that our people do not pursue learning due to process friction." We identified that hypothesis based on surveys, engagement data, managers' conversations, that a lot of times our employees do not pursue learning because it is too difficult to learn, or they do not know that learning is available, or they have to get manager approval, whatever it is. We call this process friction, and from there we fleshed out our hypothesis.

So, that is our hypothesis backlog. So, from the hypothesis, we created a test, a cheap, quick, easy test. So, from the hypothesis where we believe our people do not pursue learning due to process friction, we created an experiment. Now, how do I measure the success of my experiment? Well, I am taking another product approach; I am using pirate metrics. They are AARRR, which is for acquisition, activation, retention, referral, and revenue, which is essentially a funnel. So, I am not going to force my talent to learn if they do not want to, but I want to create an environment where they can adopt learning whenever they want to. So, it is really an adoption funnel. So, the first experiment we did, or the first well-formed experiment, it was around AWS. We are migrating to the cloud; AWS is our partner; we want to empower all our engineers with AWS. But as you know, training can be expensive, so we wanted to lower the cost, and what we did is we thought, can we provide training online? That is where the hypothesis is. So, we are using things like Udemy and A Cloud Guru, where it is about 60 US dollars to do the AWS fundamentals course. The other thing we did was remove process friction. So, we removed cost friction on one side, and we also removed the requirement for manager approval. So, an employee within the company can take these courses without management approval, and we wanted to know what would happen. So, the result was, within seven days... This is acquisition. We had 15% of our organization sign up for AWS. Now, these licenses were updated two days ago; it was closer to about 30% now, and that was just with these two changes. So, the heart of this is just about creating really cheap, really quick, really fast experiments.

Now, we faced a lot of challenges in doing this. We have been doing this for about four months now, give or take. It really required a mindset shift, even within myself. Being agile requires a mindset shift, because it is not only about the big things that I had to change about how I thought about it, it was even the little things. Do I have data to support my assumption? Can I develop this in as small a piece as possible? Sometimes, it is even about working within my doubt, that if the data shows one way, but I believe another, which one do I trust? Do I trust my opinion, or do I trust the data? So, these are all things within the experimenter's mindset. The second thing is, we had to learn how to experiment by experimenting. So, the experiment I showed you was the first well-formed experiment; the previous five were horrible, and we failed, not because the hypothesis was rejected, but because the experiment itself was bad. So, we had to learn how to experiment. So, much like coding or coaching is a muscle, experimentation itself is a muscle. So, as we developed, we became comfortable with failure. Now, I want to clarify what failure means in my context. Failure does not mean whether I confirm or reject a hypothesis; it was whether I really screwed something up or not. Being an innovator, trying something different, failure can be just around the corner, and you have to be really comfortable with that. Now, what we have found is that a lot of times, failure has no consequence, or it has no irreparable consequence. So, it is just about being comfortable with repairing and moving on. Moving quickly was really difficult in an existing 20-year-old company. We were trying to move quickly, and we were getting blocked left, right, and center. This goes back to the mindset, where it is very easy to say, "I cannot move quickly because of bureaucracy." But the mindset here was, "We cannot move quickly, so we will change that bureaucracy." So, we were working with HR, and we were breaking the processes and changing our processes, so that we could move quickly, experiment. Lastly, it is about measuring outcomes, not activities. We had a plan of what we were going to do, all the steps we were going to take, but I do not know if I am making an impact unless the outcomes happen. So, it goes back to outcomes.</p