Culture. People. Awesome culture. Poor culture. Good environment. Refreshing work atmosphere. Pathetic place…
These are all phrases that I have seen in articles, blog posts and workplace reviews that I have read lately. I have also been seeing a lot of how-to articles on what a workplace culture should be. I have already written a bit previously about Google’s culture. Culture, whether you think it is a thing or not, is always there. In a company, even if you don’t consciously or formally address the issue of culture, there always is. Well, if you don’t shape it, it will not be what you want, but there will be a culture nonetheless - good, lousy or otherwise.
I am fascinated by the study of how a company’s culture evolves. There is of course, the broader question of how culture evolves generally - society, community, religion, etc. But we are getting ahead of ourselves.
Does your company have a culture?
Ben Horowitz, legendary investor and enterpreneur, has this to say about culture:
“Truth be told, either you can shape your own culture or it will inevitably shape itself.”
So why is culture important? And mind you, culture is not having yoga classes at office - that’s a perk.
So let’s start with why culture should be deemed important. Again quoting Ben Horowitz,
“The primary thing that any technology startup must do is build a product that’s at least 10 times better at doing something than the current prevailing way of doing that thing. Two or three times better will not be good enough to get people to switch to the new thing fast enough or in large enough volume to matter.”
Hmm…interesting.
Culture matters to the extent that it can help you achieve this goal.
Every employee has the will to take up this kind of responsibility. It is the executive’s and the manager’s job to pave the path for achieving this. Brian Chesky, from Airbnb, says this about culture,
“Culture is simply a shared way of doing something with passion.”
I agree.
Let me back up a bit though, and get to the meat of this post - because culture is far too big a topic to finish off in one post; definitely not.
So, the primary thing for any technology company to do is to build a product that is 10x better than the competition. How do you even do that?
Hint: your people.
When your people have a sense of purpose (not to be confused with a sense of urgency), when your people understand the overall goals, the scope of the challenge, that is when a great product is made.
I recall this conversation with a set of business analysts on my earlier team. They were primarily subject matter experts, and hadn’t played the role of BAs before in their careers. For the initial period, when the work revolved around defining the product in their area of expertise, they did ok, considering they already knew the stuff.
However, when we got into discussions regarding the future roadmap, a lot of their assumptions started to unravel. I sat down for a set of frank discussions with each of them.
Firstly, I started off with asking them to explain their understanding of what the product stood for, and with
- what are we doing currently
- where do we want to go
- how do we get there
- what will it take to get there
It turned out that almost all of them had very vague ideas of the future direction. Now all of these people are intelligent and smart. They hadn’t yet just started looking outside of their world view.
So what does one do? I believe it is our deepest responsibility to give our team members the ability to look beyond what they see today, because that’s what I would expect from my leaders and managers.
Good culture is also helping your people go beyond their abilities, so that newer, greater opportunities can open up.
So, I got back to basics.
Remember that this set of people had never been business analysts before. And they had been subject matter experts for a “projects” division. It is difficult for everyone to understand the hard transition from “projects” to “products”. So I began with this.
“Projects” vs “Products” - the customer development difference.
From a requirements definition perspective, the difference between a project and a product is derived from who provides the requirements.
In a project, it is either a client or a group representing the client, who has the final say in all requirements. The model to work with this ruleset is quite well-defined. Companies like TCS, Cognizant and Infosys have perfected the way to deliver projects on time, in quality.
Note that I am not taking sides - both these models are just different.
In a product, the requirements come from a subset of the potential customer base. Of course, this subset of customers won’t come to you with a detailed set of requirements.
The Product Manager and/or the Business Analyst needs to
- get out of the building,
- talk to customers,
- find out the pain points they have
- come up with likely solutions
- prioritize implementation
- translate into dev team-speak
- ship
PMs or BAs should not define a product by themselves on their own. Thinking up the product is not their responsibility.
This point needs to be repeated.
The primarily role of a PM/BA is to talk to customers, glean the customer pain points, then define the solution and help the dev team build and ship. If and only if we do this right, then a 10x product gets made.
In my career until now, I have built a lot of products and projects. I am supremely confident I can take up any software product idea, and get it built and shipped. It’s easy because if you get the requirements right, and the team understands it fully, then it is just a matter of consistent execution.
However, the BIG point here is - “getting the requirements right”. Development is costly, more so if you end up ultimately having to rebuild the product, because you didn’t get it right in the first place.
I told these set of people, and I say this to you -
“Concentrate on the key questions - are we building the right thing? What are the right things? What will take to make this a 10x better product than the competition?”
I don’t have all the answers. Nor do you. Your customers do. And they will not tell you what they need. Not specifically. And sometimes, you need to ignore them.
Apple did not go out and ask people how to build an IPhone. Well, maybe they did. My point is you don’t ask a customer what they would like their phone to be and expect them to list out the IPhone feature list.
But getting out of the building and asking customers is your best bet for success. (here is the part where I pay respects to Steve Blank).
The second thing I told them - a product manager or a business analyst needs to be technically literate.
That means being able to have a meaningful conversation with developers - understanding and speaking, at least on a basic level. You shouldn’t necessarily know how to code. If that was the case, you would be a developer, wouldn’t you?
The technical literacy part comes easier to me - I am a computer engineer by education and I have coded in the past, and I still can code rudimentary projects in Laravel. But those of you who wish to pursue product management / business analysis and lack a computer engineering background, it is absolutely mandatory to acquire these technical literacy skills.
I don’t know what this post now stands for, but what the heck.
Ultimately, I will end with an extract from Rohini Vibha on the role of a product manager (and business analyst),
“If a user doesn’t understand your product, that’s on you, not Marketing. If your product comes at the wrong time, that’s on you, not Strategy. If a user can’t find the button, that’s on you, not Design.
And if a target user has no use for your product, that’s on you, not him.”