Before working in Tokopedia, I work for a small startup with 10-11 people. I was the only designer, almost every design decisions fall to me. I got used to do everything by myself, I can make things happen quickly since I work closely with the CEO. But everything's different in Tokopedia, the role was more specific, the challenge were more severe and it shaped the way I design product currently, and here's what changed :

01. Product is not always the answer. Always think the easiest way to get things done.

I was indeed amazed by Tokopedia's internal system full with e-mails and google sheets, managed manually by employee, it was so flexible that it could cater so many use cases. This become our own challenge that we should create a product that could match such value and flexibility, otherwise, what's the point building the product.

Other benefit of providing less product-centric solution is the ability to provide faster solution so our users can gain the minimum value faster while waiting for the ultimate product solution.

02. We can be as idealist as we want, but missed opportunity won't ever come back. Timing matters.

I always thought every design process step are non negotiable, but there are several times we missed opportunities to introduce our product to the users because we wanted it to be perfect and cater so many use cases.

03. Product vision matters. A lot.

Without this, there's a high chance we build the wrong things. Building wrong things cost a lot. Before this, I only thought how the interface should work right now, without thinking future context on how it should scale nor having certain consequences.

04. "If I had asked what they want, they would've wanted a faster horse".

This famous Henry Ford quote is indeed should run in every designer's mindset. Before this I thought what user's said is the only thing that matters. Little did I know, they also need our help to think the ideas they would've never thought before. We should combine every aspect on the empathy map to be able to provide on point solution.

05. Stakeholders are our users too.

Every division has certain KPI and oftentimes it wasn't aligned with our KPI. Being user-centred without empathizing on stakeholders could lead to solving problem that less impactful because we only see from one perspective. It's our job to create design decisions that is supported by everyone, using win-win approach.

06. Misunderstanding are inevitable, over communicate anyway.

The bigger the team, the more complex it becomes. Unlike in a small startup, there are multiple context that we have to maintain in an organisation as big as Tokopedia. Having written documentation of all process can enhance the collaboration.

07. Always. challenge. the goal.

Who would've known that we can't always be a "yes" person, before startup culture were trending, the trend of corporate culture were always top-down, had we challenge or say no to the direction, we could've ended up in trouble. Today, not challenging the goal enough could lead us to build products or projects that ended up on hold or deprioritised. Save your time and effort by dig deep into the objectives, and help the stakeholders set the right goal that's sharp and clear.

08. Encourage everyone on the product team to empathise.

If we keep the users to ourselves, other team and stakeholders will tend to compromise any solution recommendation that's too much of an effort.

09. A new division takes time to mature. A certain way to learn is to build as many product or features as possible, to fail early and learn fast.

To find the best framework, a team needs to evaluate past works and learn a lot from early failure.

10. Foundational research first, decide product later.

One of the reasons why a product/project is on hold or deprioritised is because designers were not included in quarterly product planning, and the planned product didn't have strong foundation on why it should be build. To actually make value out of products we build, we need to do foundational research first and prioritised which problem worth solving.