top of page
  • Writer's pictureYuval Eitan

Unlocking 10X Growth - A case study

New products come and go every day. 2018 for example, saw the number of mobile apps grow by 6,000 every day in Apple store & Google play store. Competition is fierce, for both acquisition and retention, and every day crowns a new champion for the attention of the users. It is only the exceptional products that manage to break through the collective barriers, prove real and lasting value, and reach the holy grail of product companies looking to succeed - "Scaling up" your product. Here is one product that managed to do it right.



Walla! Communication is one of the largest News & Entertainment platforms in Israel, boasting a wide portfolio of web and mobile products, all of them offering original content. Early 2017, a new product, "חמ"ל" ("Hamal") , was added to company's mobile app portfolio, aiming to create a new source for unfiltered, 1st to publish, news-focused-social-network. The product was innovative at its core, and seemed to have potential to succeed - however, it failed to create early momentum and traction. By July that year, despite dedicated marketing efforts, the app was seriously lagging behind expectations. It was disappointingly ranked 4th out of 6 main products in the Walla! News mobile apps portfolio DAU ranking. A marketing survey from August 2017 put "חמ"ל" Brand Market Awareness on slightly less than 2%, out of the relevant market. User Engagement KPIs were below par at best, and were on the decline.

The main question hovering over the product was "Is the product capable of scaling, or is it doomed to remain a niche news app?"

Fast forward 6 months...

By February 2018, the app was the main users growth engine for the entire company's products portfolio, increasing overall mobile portfolio DAU by 25%. At that stage חמ"ל was contributing 30% out of total mobile app portfolio DAU, ranking 2nd out of 6 mobile products, and climbing fast. Other Engagement & Retention rates were showing equivalent progress, and "חמ"ל" was becoming a unique household name in the 'red ocean' that is the Israeli news industry.

Here is the story of how we got it there.


The Product

The "חמ"ל" (Hamal) app, (a common expression in Hebrew which translates as 'OP center') can be best described as combination of a Newsflash ticker on steroids, with a social network.

Users upload short news reports and related media items to be published in a public vertical news feed, which is the main frontal part of the app. The User Generated Content (UGC) is combined with selected editorial content to help dictate conversation topics.

This content model enables the product to not only have an abundance of fresh content in the app, but also have an 'army' of reporters located in all geographical areas, (almost) not bothered by censorship and other restrictions.

All these results in a fast-to-publish, comprehensive, easy to digest news source, and gives the users plenty of room to express themselves. Theoretically, it had what it took to succeed. In practice, it was performing way below its potential, and needed to be re-thought in order to reach its goals.

The Challenge

Israel is a hotbed for news-worthy events, that's a well known secret.

As such, there is an abundance of news and media platforms - all competing on the users attention, all trying to be the first to publish.

Becoming a major player in such a 'red ocean' is no small task. To become one, you had to count your daily active users around a minimum of 6 digits, and even than you would be struggling to catch up with the old powers of Ynet, Channel 2 News, and Walla!'s very own Walla! News. Nonetheless, this was our goal. We were to establish ourselves as the leading mobile app for breaking news, a lightly defined niche in the news products market, but more importantly - grab a sit at the 6 digit main table of Israel's news mobile apps market. We were tasked with reaching that goal within 5 months.

My Role

Around the 2nd half of 2017, I've entered my role as Product Management Lead for the Mobile department at "Walla! Communications".

Under my responsibility were 6 native mobile products - Walla! News (the company's flag product), Sports, VOD, Entertainment, VR & our focus for this case study - חמ"ל ("Hamal" )

Each product is unique in its offering, target audience, life-cycle phase and naturally even budget and organizational focus.

Alongside me worked an extremely capable SCRUM development team, consisting of 6 front-end developers (3 Android & 3 iOS), 1 WS developer for Back-end support, 1 Manual QA tester and a technical team leader. In addition we were closely supported by Marketing, Design and BI teams.

I had set the Product roadmap for the entire portfolio, composed all feature specs including UX definitions, managed development cycles, and coordinated marketing efforts pre and post features launches.

Aligning stakeholders with our strategy

The חמ"ל app, despite its slow start, and despite being just one out of the entire portfolio, seemed to be the one with the highest potential to drive the portfolio forward faster.

It was targeting one of the most sought after needs in the news vertical (be the "1st to publish"), and had a unique USP to base upon (UGC) - both enabling it to face relatively limited competition for its specific niche offering. If handled correctly, I was certain we could solidify a substantial position in the market, before competitors join the chase by launching similar products.

We just had to do it right.

Nonetheless, It took a bit of efforts persuading some of the senior management to put Hamal in the company's spotlight, as not only did the early results were disappointing, but it required setting aside major pipeline projects in other portfolio products. However the potential was evident, and with Hamal being a relatively new product, most still wanted to give it a real chance to redeem itself after its slow start. Luckily we've succeeded in our persuasions. Not only did we get the senior management on board with our plans, but once we've shown some early "low hanging fruit" success, our efforts were given another major boost by allocating substantial budget for an acquisition campaign due within a few months.

And so we focused the lion part of our team's efforts on חמ"ל.


The process

In the following text you will find the detailed process we have undertaken in order to reach our goals. I've broken it down to 3 main phases:

  1. Analysis - Setting our starting point: Understanding the current user journey, strengths and weaknesses of our product, and concluding our improvement opportunities.

  2. Planning - Deciding where to place our efforts: Creating our Backlog, Prioritizing features and building our Product roadmap

  3. Execution - Describing in detail what we did in each area we've decided to target, and why.

Here we go.


Phase 1 - Analysis

Drawing the picture

First and foremost, before made any changes, we needed to understand what we were facing.

The app was already live for several months, which meant we had the privilege of relying on actual usage data and user feedback to understand what was working well, and what needed improving.

Another crucial factor was that due to the early stage of the product, our main focus was user growth.

We knew we could rely on other veteran products in the portfolio for generating steady revenues. That meant that we could focus most of our resources on growth - building a strong base to the Hamal product, and making sure the users love it and keep using it, and not split our attention between that and aggressively increasing revenue streams.

That was a privilege not often encountered, and we planned to take full advantage of it.

So with our OKRs revolving around increasing overall numbers of Engagement and Acquisition, we could begin mapping what we needed in order to reach them. We started drawing the picture for the Analysis phase by taking the following steps:

  1. Identify main KPIs

  2. Evaluate current main KPIs scores

  3. Map the initial user journey

  4. Review user feedback

Once we had these, it would be easier to decide where to focus our efforts (Planing phase) in order to apply changes/new features to the identified key areas (Execution phase).


1. Identify main KPIs

We started off by looking for the usual suspects under Acquisition, Retention and User engagement. As each product and industry has its different KPIs, it was important to make sure we're focusing on the relevant ones in the sector of News & Entertainment mobile apps.

The main key elements in the 'News & Entertainment industry included:

Conversion --> viewing with a content item

  • Item views

  • Number of sessions

  • Sessions time

ROI calculation --> based on the amount of ads a user is exposed to while consuming the content (Business model being advertisement based)

  • page views

  • Media viewes

  • Number of sessions

  • Number of unique users

After determining our high level goals, we turned to set our Engagement KPIs.

Those revolved around amount of content items consumed, time spent within each item and overall session, specific engagement with special types of content items (Polls, Videos and more) etc.

In addition we were tracking the standard Acquisition rate and sources, Retention rates, and every user engagement indicator we could point our trackers on, general and mobile specific.

2. Evaluating current KPIs scores

Using analytics tools like Google Analytics, Fabric and Google's BigQuery, we've deducted some very interesting conclusions, to later base our action plan on. Hand picking some that we identified as potential to provide a good basis for action, you can see for example:

Areas to preserve / leverage:

  • Over 2/3 of users accessing the app, did so following push notifications.

  • Users who generate content ('Writers') are X2 more engaged (# of sessions, session time) than users who only read and do not post ('Readers')

  • Increasing the number of push notifications sent did not had a linear affect on the # of users opting-out of receiving push notifications (or removing the app altogether)

  • Corresponding users' feedback regarding push messages, addressed mostly issues with their content and not their frequency

Areas for improvement:

  • Average session time was very low. Users appear to launch the app, view latest update and exit immediately.

  • Average Page views count within a single session were minimal. Users were visiting the app's main feed and leaving the app.

  • User generated content (UGC) quantity was below par.

  • Number of contributors to UGC was limited to a handful of users.

  • Organic growth was minimal to non-relevant.

  • Shared content numbers were low to non-relevant.

3. Mapping initial user journey

We spread out all existing app screens and their relations, familiarizing ourselves better with our users' main flows and looking for key obstacles for user navigation.

We were looking for opportunities to improve those user flows, in order to help increase the users' engagement with the content.

We've identified 2 areas we felt we could optimize to bring a significant positive impact:

A. Limited engagement opportunities

Launching the app leads the user directly to the main feed. The main feed displays all the news items chronologically, and was effectively displaying the entire content available. So basically the most common user session involved the user launching the app, scrolling down through the content, and hopefully encountering a streak of relevant items before exiting. It was all quite random, and we've had little room to optimize the content for the user's interests. Almost all pages other than the main feed were supportive functionalities which were hardly ever visited. The only other part relating to the content was the 'write a post' page, enabling the users to generate content.

The app's initial structure was minimal and effective in getting the user straight in the action. However, there wasn't enough for him to do once he got there. If we are to keep the user engaged with our content, and in addition generate more page views to increase monetization opportunities, we first needed to create more opportunities for the user to engage with the product.

B. Limited exposure to top content

Another perspective for the lack of content issue, had to do with getting the right content for the user. The app's main feed was chronological, meaning the items are sorted by 'Newest item first'. This might have done a great job serving our goal for being updated and relevant, but it also meant that popular news topics that could generate engagement were being pushed down the feed, minimizing their exposure.

We had to find a way to expose our top content to our users, without coming out as not up-to-date.

4. Analyzing User feedback

We benefited from the app already being live for a few months, and the fact that a core group of users was highly engaged and vocal, providing feedback both directly to the app support and in the app store/google play reviews.

Analyzing these feedback pointed several issues which were all taken into account. Here are a few examples from our app stores reviews and customer support:

  • "There's too much items about traffic and weather, not enough 'real' news"

  • "Let us customize the feed to show only topics we care about"

  • "Allow push-notification sound customization"

We of course took all feedback into consideration, and prioritized all relevant ones based on things like volume of requests for a certain feature, urgency, effect on our target KPIs and so forth, but not only those. We've also used the users feedback to identify "hidden requirements". Let me elaborate slightly.

IMHO, One of the most important parts of the product manager role is taking that ultra-specific client feature request, and notice that it is actually hiding behind it a much more comprehensive requirement for the entire product.

Let's have a look at the all famous quote of Henry Ford (or Steve Jobs, or none of them, depends who you ask..):

"...If we asked people what they wanted, they'd say faster horses..." ,

This quote is usually given as an example on how to build products while ignoring user feedback.

I have a slightly different approach to interpenetrating this quote. .

The way I see this story, is that those users Henry Ford was referring to, actually did know what they wanted. They did know they wanted a faster method to get from A to B. They just didn't know how to say it. So they used the terms they were familiar with. "Give us faster horses" they said. Henry ford deducted from it that they needed a faster method to get from A to B, and so he built a cart powered by a combustion engine, perhaps better known as the 'Model T' Ford Car.

An effective product manager knows how to identify the user's 'hidden requirement' out of its feedback or complaint, and turn it into an opportunity to make its product better, or hopefully, make it the best in its class - Since he truly understood what the users needed, before they did.

That specific trait, is what makes Henry Ford and Steve Jobs some of the best product managers of all times.

An effective product manager knows how to identify the user's 'hidden requirement' out of its feedback or complaint, and turn it into an opportunity to make its product better, or hopefully, make it the best in its class - Since he truly understood what the users needed, before they did.

So back to our young app...

Some of the user feedback we received was definitely in-line with our data and our goals. Those that met all criteria were prioritized first. The rest went into different stages of the roadmap and backlog. But the important ones for us, were the ones indicating a more comprehensive requirement to the product, or perhaps a usage trend that can be leveraged.

Let's take a look at the first 2 of the feedback examples above, to show what 'hidden requirement' each might be hiding:

  • "There's too much traffic and weather related, not enough 'real' news"

  • "Let us customize the feed to show only topics we care about"

One is a complaint, the other is a specific feature request. However these two genuine user comments, actually imply of the same thing: The content is not always relevant for the specific user.

So our action item here was - Making sure the content in the app is as relevant as it can be for maximum possible users (without creating, yet, a separate app for each user..). We could choose personalization, we could choose to go with the majority of the users, or any other solution that would provide the highest ROI. But identifying the actual need of the user is what determines if we are investing our resources effectively. And we got a clear indication here that we at least needed to optimize our content.

Another interesting example was the request for push customization (We were using default device sound at that time):

  • "Allow push-notification sound customization".

The request itself was repeated enough times that we addressed it twice within a short period (creating a customized app unique sound, and later adding a feature specific sound and enabling selection between sounds). However the need for specific push sounds was not the main conclusion from the feedback, nor was the multiple requests the actual reason we addressed it with 2 specific features within a short time period. It was the message behind the requests, that were far more important in our minds:

  1. Users were asking to identify between the push sound of our app to other apps on their device. They wanted to know when it was us who sent them a push message, reasonably enough so that they could respond to it and not dismiss it by hearing as "just another push notification".

  2. Users were specifically addressing our push notifications sound. To us, the mere specific referral to the push messages confirmed that they saw it as an important interaction channel with our app.

I must say that throughout my career I was yet to encounter an app so effective with using push notifications for communicating with its users, as our Hamal app. That was an important notion, and we were definitely going to leverage on that.

More about the technique we used to determine those requirements can be found in the post "Your users are complaining? That's a good thing!"


Phase 2 - Planning Selecting areas for improvement

After analyzing the answers we got from our data, user journey mapping and user feedback conclusions, we were left with many parts of the product that could be improved. Nonetheless, we had to focus our efforts if we are to be effective.

The Planning phase was broken down to 3 generic steps:

  1. Backlog creation

  2. Features prioritization

  3. Product Roadmap assembly


1. Backlog creation

We focused first on the areas that had the biggest potential to improve our main engagement KPIs, and contribute to our current growth focused strategy.

After some discussions, we've decided to apply our efforts in the following 4 areas:

  1. Increase exposure of potentially engage-able content (Targeting session time and # of daily sessions)

  2. Increase conversion rate (Targeting number of read items per user)

  3. Increase UGC content volume and # of contributing users (Targeting number of 'Writer' type users and # of items created per user)

  4. Increase organic growth and content distribution (Targeting content share and organic acquisition)

Each of these areas selected for improvement was set with a KPI Target as described, deriving from our high level OKRs.

While these KPIs were created as means to measure ourselves and make sure we are on the right path, it is important to note that they were adjusted constantly, much due to the fact we were handling a new product without much of a benchmark to rely on, and that meant we had to occasionally adjust our estimations.

The idea was to not only achieve the strategic DAU target set by the management, but also set a clear path for the app's evolution for after we reach that goal..

So after we had a good idea on our product's current state, and we knew where we wanted to improve it - it was time to start creating. Now we had to produce actionable features that would drive those areas upwards.

We took our time coming up with ideas for the best ways to improve each of our selected areas, involving in the process as many relevant company functions as possible while still remaining effective.

At first, each selected area was treated as a separate problem, and features were addressed to solve it specifically.

Nonetheless, since we've knowingly looked to improve several problems, we could look for more holistic solutions, that contribute in more than just one area.

We piled up around 70-80 high level features between all 4 areas.

These would be the backbone of our Product Roadmap, once we prioritize and align them with our workplans.

2. Features prioritization

Once we had our backlog, we had to make sure we focus our efforts where it matters.

This part is always hard for everyone, as many relevant features might be pushed back to the bottom of the backlog not because they don't bring value, but simply because other features bring more value.

To make sure we do it efficiently, we've started prioritizing our backlog features in 2 stages:

A. Executable scope

We had limited time and resources, and needed to define a reasonable work scope that was executable within our time and resources constraints.

We've had roughly 5 months, with a predetermined team and minor room for adjustments (i.e bringing in reinforcements from other teams ; new hiring was irrelevant, mainly considering the limited timeframe and required training time).

To make sure we stick to an 'Executable scope', we took the following steps first:

  • Calculated available resources (mainly Dev, Design & QA man hours)

  • Provided a high-level time estimation for each of the current backlog features

These enabled us to consciously decide which mix of feature would provide the highest potential benefit, while still keeping within our available resources capabilities.

B. Prioritization

In order to decide which feature mix will compile our product roadmap, we had to rank them in such a way that would create an internal consensus of which features are more important.

This is one of the most challenging parts of creating a product roadmap. Everyone involved has its own opinion on what is more important, what brings more value, what would be more popular with the users and so on. It is almost unavoidable, as product teams are often compiled of smart, free thinking individuals, and our team was no different.

The key to creating a consensus nonetheless, is in finding 2-3 common denominators that the entire team can agree on. These would allow for a common point of view, and a common ranking which leaves minimal room for subjective judgement. Once our team have these 2 we can create a consensus, utilizing all the brain power of the team while leaving only minimal number of decisions to be made in a 1-sided manner, Instead of relying on just a single brain to make all these decisions in the first place.

The key to creating a consensus nonetheless, is in finding 2-3 common denominators that the entire team can agree on

Features Prioritization Tools

Those common denominators we used to help us prioritizing our backlog, and also allowed for easier communication with all stakeholders involved in this process, were tools based on XY axis maps:

  • Usage Frequency VS % Users - How often would a feature be used, and by how many users

  • User Goals VS Company Goals - How the feature contributes to user goals and how it contributes to the company goals

  • Effort VS Reward - what it takes to develop or maintain the feature, compared to what it contributes to the product and/or company

After evaluating our backlog features with each of these 3 tools, we could easily identify our most valuable features.

Feature Prioritization template - Usage frequency VS # of Users (, - direct link to board)

3. Product Roadmap assembly

We had our backlog prioritized, and our features' effort estimation and executable scope constraints clear - we now could quite easily assemble our Product Roadmap.

We started off by deciding what is IN and what is OUT.

A short (and sometimes ruthless...) process first put in our top priority features, until our resources capacity was reached.

Then came the (cumbersome) part of negotiating features in and out - however it was still effective and quite productive, since everything had a specific price, and it was very clear that in order to get a feature in, equivalent effort estimation sum had to be taken out. So it was basically a matter of comparing 1 feature against another, which is definitely easier then trying to decide yes or no for 70-80 features simultaneously (our initial backlog).

At the end of this ruthless thinning down phase, we had our initial backlog which consisted from about 25 high level features.

Now we decide what comes first. Or basically, how do we distribute development and launch of those 25 features, across the 5 month timeline that we had - in order to meet our goals in the most optimal way.

For that we had 3 perspectives to consider, that would help us decide on the entire timeline:

  1. KPI Goals' timeline requirements - while we already took our goals into account when compiling the features list, some of the features needed some time to gain traction. We couldn't just release them a week before our deadline and expect them to immediately create an impact.

  2. Development constraints - how much effort is required and how we can fit it within our overall portfolio development plan (remember we still had to maintain 5 other products, which had their own agenda)

  3. User relationship and visibility - this elusive phrase is a key aspect in modern product, and specifically, mobile app economy. With the likes of Facebook and co releasing a new version every 2 weeks, users have grown to expect meaningful new features being introduced frequently. We needed to keep a gradual flow of front-end changes so that our users feel that we are constantly working to improve their experience. While we were always working on the product, some of our deliverables might impact behind the scenes, where not all users are aware of the improvements. We needed to make sure our users feel that we are constantly improving, by maintaining a steady stream of front facing changes to our product. We've made sure to frequently release such features, and to not allow more than 1 month between 2 significant front-end features releases.

At the end of all this, we had our product roadmap.

Now comes the part of executing our plans.


Phase 3 - Execution Manifesting our vision

After we had outlined our high level plan and sorted our priorities, It was now time to dive-in each of the key areas we've decided to improve on, and create their respective solutions.

The following describes the features we’ve actually added, the problem they solved, and how we chose these solutions on top of other alternatives.

Reminder - Key Areas for improvement:

1. Increase exposure of potentially engage-able content

2. Increase session engagement

3. Increase UGC content volume and number of contributing users

4. Increase organic growth and content distribution


1. Increasing exposure of potentially engagable content

Identified Problem

There was no option for the user to prioritize his preferred content

The main feed was sorted chronologically. That served us well for maintaining the critical "up to date" value of our product, so important in the news industry.

The meant that changing the logic by which the feed was sorted was out of the question, as it would cause us to lose an important USP.

Other suggestions included "pinning" important posts to the top of the feed. That also had to be discarded, when considering the constraints of a mobile app dimensions. Pinning a post to top of the feed would cause the feed to display potentially outdated post at first impression, again meaning we would have lost that all important "up to date" value.

So how do we enable users to easily access that "hot" content? We chose a different approach.

The solution:

Pinned "Hot" Hashtag

"Hot" Fixed hashtag; Hamal app, February 2018
"Hot" fixed hashtag; Hamal app, February 2018

We used familiar "Content Hashtag" mechanics (where hashtag represented a certain content topic), but in a more focused way. We created a new area in the main feed, controlled by the Editors Staff.

That area would contain a specific hashtag, selected by the editors for his relevance and popularity. Tapping it would lead the user to a separate page, which was basically the main feed filtered to display only posts with that specific hashtag.

This new 'fixed hashtag' isn't always present. It is only used when there was a meaningful news worthy event, that our users would naturally look information on.

This way we avoided wearing the feature out, making users blind to it in the process - and still make sure its familiar enough for them to use when it's relevant.

2. Increasing session engagement

(Detailed process description)

Identified Problem

Lack of engagement opportunities

One of our first actionable conclusions from phase 1 (research), came from analyzing the current low engagement rates. We concluded that there was an apparent lack of depth. Lack of depth from both content variety, and from the low number of engagement opportunities.

To put it simply, users just didn't have much to do in the app once they launched it. Even though they did launch the app often, they seemed to consume little content in each separate session.

The content variety part was a challenge by itself, and I will address some of it other sections (In short, solving it involved lots of training and experimenting with the content editors on one hand, and on the other hand, dedicating efforts on increasing UGC. More on that later on).

The engagement opportunities were a different matter, and there is much to be learned from it.

"The 2nd Conversion challenge"

So setting aside the content, we needed to address the app's structure itself. If we are to enable the user to spend more time in the app, meaning consume more content, we needed to create more opportunities for him to do that - something that a single dimension content feed simply had a very hard time enabling.

While that was a seemingly straight forward problem - "create more opportunities for content engagement" - doing it right is one of the biggest challenges for any product in the Media industry.

Here is a little something to help you understand the challenge i'm talking about.

An extremely useful benchmark report conducted by Mixpanel (see below), concluded that while a '1st conversion rate' for media products is one of the highest of all industries at 46% (Conversion in media = Visit app or website--> view a single content item), the rate for the 2nd conversion is one of the lowest, with only 2%...

That means, that while almost half the users who visit your news product consume a content item, only a mere 2% (!) view more than one content item.

A few examples from other industries to give you some perspective:

1st & Repeat conversion benchmarks from main industries, "Mixpanel Products Benchmark report 2017"
1st & Repeat conversion benchmarks from sample industries, "Mixpanel Products Benchmark report 2017"

The solution (overview):

"Following the Push"

So to improve those all important engagement KPIs, we needed to face one of the main challenges of the media industry, the "Repeat conversion".

But where do we start?

There are many ways to approach such a problem, but from my experience, I find that a method relying on the simple yet powerful logic of the SWOT model, always seem to generate the most effective solution.

I treat the problem as a Weakness and cross it with our market's Opportunities, or as a Threat and cross it with the product's Strengths - looking for a junctions where one of them can produce an effective solution.

Using this simple thought pattern has repeatedly been effective in shortening the time it took me to find a valid solutions to product problems, big and small.

Once we gather the best solution options, it's of course back to the good ol' develop-launch-analyze-repeat.

We turned first to rely on our strongest assets.

We had a solid core of users, who engaged with the app several times a day, and more so when real world news events happened. Our users were interested in our app, and found value in it. That was definitely something to build upon.

Adding to that impression were positive stats regarding our Push notifications - We had very high percentage of users who enabled push messages, and which hardly deteriorate even when we experimented with aggressively increasing the numbers of messages sent per day.

While focusing on push notifications, we encountered yet another important conclusion coming out of our preliminary research, which was extremely meaningful in determining how to improve those target KPIs. Between 70-80% (!) of all our app launches resulted from push messages. That is a very high number, even for a news app which are traditionally on top percentiles when it comes to push-notifications engagement.

Users were engaging with our app, and were doing so primarily via push notifications. That was something we were definitely going to leverage.

Problem drill-down:

Mind Map - Increasing session engagement
Process - Increasing session engagement

Optimizing the push-launch flow

We started off by attempting some conventional approaches, right from the start of the push launch flow, hoping to increase engagement.

For example, we experimented with:

• Changing the push notification graphics

• Adding an expand-view to the push notification in the notification center

• Changing the frequency and daily amount of push messages sent

These had little impact on the engagement numbers further down the funnel.

Perhaps unsurprisingly, as these focused more on the very early stages of the funnel, while we were trying to impact the numbers further down it.

These experiments did produce minor improvements on the push engagement itself, but it wasn't what we were looking for. It also gave us important insights, as to the level of tolerance our users had about us messing around with the push notifications settings (good news for us).

Nonetheless, quite quickly we realized that if we wanted to make a real impact in our user engagement stats, we had to go deeper down the funnel.

We had try to change something in the core aspects of the post-push flow. And so we did.

Analyzing the current user flow for push-triggered sessions immediately highlighted another major flaw.

Identified Problem:

When launching the app via push, users weren't automatically viewing the related push content

Since all the news items are served directly in the main feed, without any additional layers for user engagement (like a post page for example), it was not trivial to send the user to a specific item.

So let's say the user engaged the push 15 min after it was sent, and meantime several new news posts were published to the feed. The user now launched the app, expecting to see the news item he tapped the push for - but instead he saw the top of the feed, and had to scroll down for it, looking for the specific item he launched the app for.

When examining our possible solutions, we had to consider the entire picture.

We thought about auto navigation solutions, like auto scroll it (or similar outcome) to the relevant item. But that meant you would have to sacrifice in other places, like missing out on that latest content at top of the feed etc.

Besides the technical difficulties in implementation, we had to make sure we are not damaging the overall experience and positioning of our product as up-to-date with latest news events.

So at this stage, the trivial solution would have been to create a "Child" page where the push would lead to, right?

Well not if you recall the 2nd conversion challenge we mentioned earlier...

Sending the user to a child page would add another step between the current item and the next one, thus most probably decreasing the 2nd conversion rate even lower than it already is.

It was a classic Product meets UX problem, more than it was a technical problem of just getting the user to the right content....

So we came up with, yet again, a different approach.

It was a classic Product meets UX problem, more than it was a technical problem of just getting the user to the right content...

  • The actual solution:

To show the requested push item, we used a modal view on top of the main feed, which was partially visible behind the push related item.

The user would consume the push related post item, and when dismissing it - the main feed is immediately exposed (after already being partially visible)

App launch via push notification, "Before" & "After"
App launch via push notification, "Before" & "After"; February 2018

This solution enabled us to not only solve the problem of navigating to the specific push related news item, but also to significantly increase the successful 2nd conversions rates - ultimately improving the low engagement KPIs we were gunning for, when users were already viewing the 2nd, 3rd and so on news items, instead of having to proactively engage them for viewing.

Mission accomplished.

3.4 Increasing UGC volume and # of contributing users

Identified Problems

• UGC (User Generated Content) levels were low overall

• Not all relevant news topics were covered by UGC

• Existing UGC was mostly generated by only a small number of highly engaged users. Most of our users did not post at all.

Expecting your users to generate the content for you product, is not a trivial thing by any standard. Expecting that content to be newsworthy, is even more so.

All that was naturally taken into consideration when the app was first built. There were quite a few features aiming to encourage users to generate content, like a hassle free, in-app writing tool, CTA buttons located in prime locations like top of the feed, and others.

In addition, the 'early adopters' target audience was defined accordingly, by targeting mainly of users who were constantly consuming and engaging with news in all possible channels, and of course generating it themselves in social networks and chat platforms.

But despite those early efforts, it still wasn't enough.

Not enough users were generating content, and those who did, mostly didn't do so frequently enough.

The gaps were filled by editorial content. But if we wanted to scale our product successfully, and justify one of our key USPs, we simply had to have more User Generated Content.

We started drilling further in the data, looking for hints of the root cause for our low UGC volumes.

It wasn't long before we found something interesting. Analyzing the distribution of our post publishing numbers within our writers (users who published at least 1 post), we found out that the majority of our users had only ever posted just 1 single post throughout their lifetime as our users.

That meant we had a seriously 'long tail' of users who already showed willingness to post, but weren't actually posting. Something was preventing them to follow up and post further.

On the bright side - we learned we had a good potential of users who might just needed some help in the right direction to become a consistent 'Writer'. We had to get more of those type of users, and encourage them to post more than once.

We have translated our conclusions to 2 main requirements, that would focus on improving the following KPIs:

Increasing UGC; KPI goals & their Action items
Increasing UGC; KPI goals & their Action items

In order to be effective in our solution, we decided to approach it from 2 different product aspects:

A. Content strategy adjustment

B. New user engagement features

We've made several experiments in each of these 2 aspects, trying to test the water quickly with each approach and get user feedback to see what's working better.

Naturally not all our ideas proved successful... Here is a bit of what worked better:

A. Through the content

The solution

Curated topics - Proactively encourage users to post on a specific curated topic.

One of the first things that started producing real value, and with minimal efforts, was increasing the in-app communication with our users, while focusing on approaching them as a community.

We had the editors proactively guide the users on relevant news topics/events that were happening now, that they could post on - and encouraged them to do so.

increasing the in-app communication with our users, while focusing on approaching them as a community

This enabled users the opportunity to publish their content, in a less intimidating fashion - as they were doing so as part of a crowd, after a proactive invitation. In addition, this was saving them from making main posting flow decisions (what to post about? when to post?), and so increasing chances of user actually completing the post flow.

For example, when there was a major strike in the airport, we've asked the users who are there to publish photos of the crowds waiting for their flights etc. On another example, for the country's independence day, we've asked the users to post their photos of the military parade. Major storms were also a reason to ask for photos and videos of floods, storm damages, or even recording of the storms itself.

Note that we usually ask for photos or videos. These add to the viral potential of such a post, but more importantly - they are easier to produce than a text based news post.

These might not be 'Landing on the moon' level news scoops, but that is exactly why they are so successful - they give an easy opportunity to participate and enhance the experience, those users who want to publish but do not always feel comfortable doing so, often not confident in their writing abilities etc.. but it's easy taking a photo or a video.

On the long run, it also helps getting genuine UGC news scoops. As once these users get comfortable publishing, they will be more aware to the opportunities around them and ultimately increase the chance of running into and publishing real news scoops.

B. Through the features

The solution

Enabling Comments - Creating additional room for users to express themselves

Adding the ability for users to comment on posts, was a feature that was subject of heavy discussion from day 1. While it was evident that adding comments had the potential to impact the app in multiple engagement aspects, we had to overcome some inside resistance to make it happen.

Dealing with multiple opinions are an integral part of a product manager's work and this was nothing different. In this case, several stakeholders within the company suggested that adding comments could push the product from the original vision, of an unbiased news reporting tool, to a platform for personal opinions and political debates at best.

This was indeed a risk, if we didn't manage to successfully moderate the content in later stages. However, it was one we had to take in order to make the product successful.

Adding comments was a feature that indeed impacted multiple engagement KPIs, including our targets ' #Of Sessions' & ' SessionTime', and was a big leap forward for the app. I however want to discuss it from the aspect of driving forward UGC, since this move had a big impact on our Writers user base.

New comments feature (Feb 2018); Had positive affect on both engagement and UGC

The first major positive impact this feature had on our writers community, was artificially dictated by the way we planned the feature, or more specifically - the steps that enabled a user to comment.

Log-in to comment, and the "1st post barrier"

We conditioned any comment publish by having the user log-in first. Until then, the only other action that required logging-in, was writing a post, meaning becoming a 'Writer' type user. We also kept the same registration flow, which included a message welcoming the user to the 'Writers' status.

What all this had effectively done, besides increasing the amount of our registered users of course, was seamlessly take the user over the first major barrier of writing a post - registration. A phase which naturally had credit for the largest portion of our drop rate within the 'Post publishing flow'.

Another impact was a bit similar to what we've achieved with the curated post, but rather so more on the "1st time writers".

It was evident that the action of adding a comment to a post, as opposed to publishing a post in the main feed for everyone to see, might have been conceived as less demanding by our users.

And so we managed to ease up the transition between 'Reader' only user, to a 'Writer' user, by adding another step between 0 posts and 1 post - and that was commenting on an existing post.

And so we managed to ease up the transition between 'Reader' only user, to a 'Writer' user, by adding another step between 0 posts and 1 post - and that was commenting on an existing post.

While we might occasionally take UGC for granted when developing a UGC based app, it is actually one of the biggest challenges in such a product - making sure your users generate enough content to sustain your product, and do so consistently.

And in order to make sure that happens, we need to understand the way the human mind thinks. It is true for any user based product, and more so for a UGC based product.

It is vital to understand what encourages your users create their content, and equally so, to understand what holds them back from publishing it.

As we learned from our product, one of the hardest obstacles for a user to was plain fear of exposure. While it seems to us that people feel comfortable posting on social networks, those people we see are usually not representing the entire user base. The ones we see are simply the loudest ones. The other, much larger part of the users, are not so eager to post. Reasons varying from "not thinking they are interesting enough", "not wanting to risk being wrong", to simply being "reluctant to express myself in public".

It is vital to understand what encourages your users create their content, and equally so, to understand what holds them back from publishing it

The possibility of commenting before posting a public post, helped users transition more easily from not expressing themselves publicly at all, to "testing the water" through commenting, to eventually publishing their first post soon after.


The outcome

The impact all these changes had on our product

Following our concentrated efforts, our app's main flow and core engagement offering had both been changed significantly. A few reminders:

  • Accessing the app through different methods offered different, adapted experiences (direct launch or via push)

  • The main content item (a single news post) now had several forms (In feed - as before; Push view and post page - both were new)

  • New user engagement opportunities (Post page, commenting on a post, Curated UGC topics and more)

(Left) Initial screens flow, July 2017; (Right) Updated screens flow, Feb 2018; Main flow line in red, new additions highlighted in blue

Immediate impact

The comprehensive effort had seen quick positive impact overall. We could already see fast paced improvement, even considering the short time (0-2 months) that passed between writing these lines and launching individual features.

Some of the features (comments for example) were launched just several weeks before writing these lines, but already helped breaking several previous records, like DAU and Daily visits, with top engaged posts seeing hundreds of comments to each.

Some notable KPI changes

• Target DAU was reached mid-December - The number of users regularly visiting the app on iOS and Android risen significantly, breaking the set DAU goal 2 weeks before our target deadline. Average DAU improved by 470% over the 5 month period, aided much by a very successful acquisition campaign.

• Daily Average # of sessions per user had increased by 38% over 5 months. Users were visiting the app more frequently, and engaging with it much more as specific features' engagement tracking indicate.

User rating feedback improved significantly - App stores rating climbed from 3.8 on both stores in August, to 4.3 in google play store, and 4.1 on the Apple store by December.

• Number of users registered to push have climbed by more than 10% on average between the 2 mobile platforms

UGC - Number of contributing reporters have increased by more than 25%.


What's next

How we planned on staying in the lead

The חמ"ל (Hamal) apps have now ( February 2018 ) accumulated sound reputation and a large enough user base, helping it achieve a status of a respected brand in the Israeli news products industry.

Ongoing feature release

You need to keep them engaged, listen to their requests and always look to improve. It is crucial to keep improving the experience for the users, not only because we want to make the product better, but also because that is what users expect. And in a competitive market like the Israeli News industry, you need to always be leading if you don't want to be left behind.


It is time to shift focus on monetizing the product.

We've proved that there is real value for users in our app, and we have now made it possible to generate substantial revenues for the company.

Content is king

The content is why the users come to our app in the first place.

We need to always strive to provide the most interesting, reliable, engaging and enjoying content for our users. For that we need to always be monitoring specific content engagement, and constantly experiment with improving the content itself and our communications with our users to make sure they get the best experience.


Thanks for reading! Want to learn more on how I can help you improve your own product?


bottom of page