Leader Spotlight: Incorporating AI top-down and bottom-up, with Ram Almog
Ram Almog is Director of Product Management at vcita, a business management platform designed for SMB service providers. He began his professional career as a co-founder of Mindri, a start-up that developed technology to revolutionize treatment modalities for learning disabilities. Ram then joined Edusoft as a project leader, where he eventually became Head of Product and, concurrently, co-founded Red-id, a boutique product consultancy. He later served as CPO at To-Be-Education and as a group product manager at StreamElements before stepping into his current role at vcita.
In our conversation, Ram shares his experience helping reshape how organizations think by adopting an agile, adaptable culture. He also talks about how vcita embraces a top-down and bottom-up approach to AI, i.e., one that is encouraged by top leadership and incorporated down to the lowest levels.
A mindset for empowered teams
You owned your own company for more than a decade. How did you move into product management at vcita?
It's a strange story. I used to have my own video production company. My background is movie-making, and one of my clients was a high-tech company. I made video productions for them, and one day, I was calling to upsell something, and I got an answering machine. The voice was that company’s product manager, who no longer worked there and therefore needed a replacement. So, I called the company and got hired into product management. It was purely opportunity-based
I later became Head of Product there, and after that, I went back to being an independent studio owner, which included product consulting and user experience. We did tons of projects, and after 15 or so years, right around COVID, I sold the company and became a group product manager. That's what led me here.
In your experience across those different types of organizations, how do you approach product discovery?
It’s funny because in the last five years of operating my studio, we hosted design sprint discovery mentorship for companies. You might be familiar with Marty Kagan, who talks about different product teams, including delivery teams, feature teams, and empowered teams. Discovery is very different across those three team types.
Our product organization is built on empowered team, and when you work in that type of environment, discovery has to be a continuous habit. It's something that you just do as part of your job. You need to deliver business, and then you keep on. It's not enough that you delivered. You must constantly spend at least 40 percent of your time deciding what we will do next. From a PM’s perspective, it's very difficult to change the organization in that sense — modifying the mindset is a challenge.
Having said that, PMs who have the courage to drive these kind of changes should do that. It starts with a non-excuse state of mind. Although you report and measure on delivery, keep on practicing that business outcome mindset. When you get a task, ask, “OK, how will success look?” Loop in leadership to explain the context. If a PM does that and delivers on business goals, it pushes the rest of the company in the right direction. You can be a lighthouse squad to other teams because, in many cases, you’re providing a good framework for others to follow.
Reshaping how an organization thinks
When this kind of mindset is missing from the organization, do you find that it needs to start with leadership or with the product teams?
In today's world, if you can't adapt fast, it’s not going to work. There's no future in working like that. I’ve never found the organization to be a barrier for me. I’ve worked for several companies as both a consultant and internal employee, and I’ve found that if someone wants to make an impact, they usually can.
Also, one of the skills a PM has to have is advocacy — going around the company selling your ideas, selling your product, and making people want to work with you. When other teams come to me and ask for help, I nearly always say yes and ask to be invited to the meeting. I do pay the price for that in terms of having a busy schedule, but it creates a relationship of helping others and, in turn, them being willing to help me.
Is there an example of a specific initiative you introduced that helped an organization rethink how it operates internally?
We used to run design sprints when I was an external consultant, and what's great about design sprints is they're very short, and the outcome is quite overwhelming. You get a prototype, it looks real, and you can show it to users and get feedback. That pushes the organization into not needing to spend months in research — you can achieve something tangible and great in a much shorter time.
These types of projects help reshape the way an organization thinks about things. Suddenly, department leaders have demos that are tested with users, and communicated with other stakeholders, even if it’s not the final product. This is how I see PMs truly impacting an organization.
A top-down and bottom-up approach to AI
In your work, you’ve noted a big difference between sprinkling AI into what you're doing across the organization and undergoing true AI transformation. Can you share what you’ve learned about that?
Incorporating AI in your organization is a multilevel process. We look at it top-down and bottom-up, in that both processes need to support each other. I'm fortunate that my CEO looks at using AI as a strategic play. If you don't have that within your product in a deep, meaningful way, you probably won't be competitive — you’ll dissolve. This is all happening really fast.
In terms of a top-down approach, our CEO has set a strategic goal for the adoption of AI, not only in the product but also in the organization. That helps, and once you have that power behind you, you’re at a good starting point. We were looking into it, but we still had commitments for the product and the roadmap that didn't change. We needed to keep on with our business, so we took an approach of starting with a really small team dedicated to planning and executing the transformation.
We started by identifying small, tangible wins, like sprinkling AI in the product so we can understand how it would look in our offerings. That also got our partners excited, and while doing so, we looked at it as a long-term, strategic move. We had strategic KPIs around how deeply this will be adopted and how deeply our users are going to be adopting AI features.
We had a two-year plan, and we’re 1.5 years in. Things changed, so we’ve been adding onto our goal even more and created building tools for teams to reuse what we did in our small dedicated AI team, and incorporate it into their own work.
Then, to achieve bottom up AI adoption, we ran a two-day AI hackathon. We branded the event as a company wide opportunity, making it accessible and enjoyable to all teams, including those with zero to no AI experience, and to non-tech teams too. We made the teams use our AI building blocks and eventually ended with 11 live working prototypes. Following the Hackathon (with a little extra push from the AI team), we started seeing teams use these building blocks, enriching the product with AI elements.
How do you see AI as a driver of creativity and scalability?
Again, it's both top-down and bottom-up. After our AI hackathon, we took four of the initiatives and put them into the product. This made teams understand that AI interventions are not just a creativity outlet (which Hackathon results often are), but a vital part of the product we're developing.
You have a creative burst where you are making something new and innovative, but if you keep it in that box, it'll never happen. It will not impact the organization. Our goal was to have people prototype something in two or three days, understand how it looks, but see it actually come to reality in our product.
It's not about creativity — it's about productivity. Creativity comes when you have constraints, which is why the best thing you can do is just give people constraints, whether it be time or technicality. You don't need to tell people, "Be creative," you just need to put constraints in front of them.
Understanding AI at the implementation-level
Do you find that there's a lack of understanding about that approach, especially for either junior product managers who are entering the workforce with AI already here, or senior leaders who focus on strategy rather than execution?
I think there's a learning curve. From a leadership perspective, there’s usually a gap because these individuals are often far away from implementation. There's a very misleading notion around LLMs because usually, leadership experiences them with Claude or ChatGPT. They ask a question and get a fantastic answer, especially if they keep prompting it. Those are things that LLMs are very good at, and that’s misleading.
For example, we are listening to messages coming from clients via our LLM. We're trying to understand the conversation. Say our client contacts a home improver and asks to get a quote for renovation. They write all of the details, and they ask for a quote. The LLM is most likely to recommend "send a quote" to that client, but going deep into the way a home improver works, they are more likely to set a meeting in the client's house before sending a quote, so that the right recommendation will be "schedule a meeting.”
To come up with the right recommendation, you need to deeply understand the domain. Just because a leader says, “I asked AI a really complex question and got a very detailed, reasonable answer," does not mean that we can apply this same AI to provide estimates to clients. We would come across as unprofessional, and that's not acceptable in a production environment.
Lastly, how do you view the difference in willingness to adopt AI compared to other technologies in the past?
A lot of companies are working on AI at the application-level, not core technology, models, or deep learning. Most companies actually don't need to deal with that because the models today are so good that they can be trained with other existing models or tools. Most companies will deal with the implementation of AI instead; however, even the implementation level is something that most engineers don't know how to address.
There's a huge challenge to understanding here, which creates hesitancy. For example, we are a business management system — we don't deal with a lot of features that have technological risk. We don’t often ask, “Can we do it?” Most of the time, we’re asking questions about whether this can be done fast enough or user-friendly enough. But when you go into a project and the question is, “Can this be done at all?”, it's a different state of mind. You have to spend time thinking about it and breaking it down.
Our engineers need to go through this process. They are used to getting requirements and executing, but now, they need to think about different product directions that we haven’t considered before. That back and forth between product and engineering has been shifted severely with AI.
This shift is already happening. This is going to shake the traditional roles of engineering, product, and design, and my advice is to embrace it. It’s going to come, whether we like it or not.