Yonatan Shaham's blog

How I Accelerated My Game Development by 30x Using AI

yonatan.shaham@duda.co (Yonatan Shaham) — Wed, 16 Jul 2025 00:16:24 GMT

Online payments for product managers

yonatan.shaham@duda.co (Yonatan Shaham) — Tue, 12 Jul 2022 12:30:42 GMT

Since I started in Duda, all the features I was involved in as a product manager were related to online payments: app store, client billing, e-commerce, and membership. I was also responsible to billing Duda users under a unique and complex billing scheme. In this post, I would like to share with product managers the knowledge I gained during this time. The following is some advice from my experience. Don’t repeat my mistakes! ��

The content is recommended for you in case you are:

A product manager responsible for your company’s billing systems and experience
A product manager responsible for features that involve payments, such as marketplace or eCommerce
Want to learn more about online payment

In this post you will find:

Lessons learned from my experience with designing payment and billing experiences for various user segments and billing schemes, engaging tens of thousands of users.
Terminology guide for online payments and billing.

Designing payments and billing experiences

Many of the advice here is true for any kind of product management work but becomes crucial when dealing with payments and billing.

1. Keep it simple and standard

Simplicity is always important in product design. It’s even more important with payments and billing. Payments are sensitive, people are generally more concerned and stressed when paying or when dealing with billing. Therefore all the reasons for keeping things simple and standard apply with much greater importance.

Do not innovate! Unless your product innovation is tightly tied to its pricing, payment, or billing experience. Make people understand and feel comfortable by giving them what they are used to and familiar with. At some point I coined a phase in Duda: “if Stripe does not support it out-of-the- box, we should not do it.” The reason here is that Stripe is serving thousands of SaaS companies like Duda, and if their product managers did not think that some payment or billing feature or behavior is a good idea to be part of their product, so probably no other company really needs it, and most chances that we also don’t need it.

Duda’s original billing systems included a lot of custom features. When we developed Duda’s Client Billing , we decided not to support any idea or request that cannot be created by using Stripe features as-is. And actually, we did not hear much demand for such features. From my experience, coming up with non-standard payments and billing requirements is often a result of group thinking within the company and a false sense that “we are special and should do things in a different way.”

The second reason to keep things simple and standard is immutability. Recurring prices usually cannot be changed once used in production. So each change you would like to do will require developers to first develop a new solution and then either carry out a complex migration or maintain two solutions in parallel, which is very costly.

At Duda, we have a very complex billing experience, some of it for good reasons and some for less. Each complexity we introduced to the billing system is still with us. We once analyzed a purchase popup to find out it has 13 possible states, depending on your billing state. Migrating users from our old billing system to the new one is a project that took us 2.5 years. Looking back, our unique billing model allows us to support the unique requirements of our business. But in hindsight, we would have made some different decisions.

2. Break down delivery

Another piece of advice that is always true in product management, and twice as true for payments and billing. This is not always applicable, but I encourage you to try and implement it when you can. Map out the user flows and decide which of them are a must, and which can be implemented later. Once you deliver the must, you are free to decide whether to continue straight ahead to the next flows or to attend to more pressing needs, keeping it agile.

In many cases, you can leverage features of the payment processor or billing system you integrate with to fill for the flows you deprioritize. For example, Stripe’s customer porta l is an out-of-the-box billing management feature where your subscribers can upgrade, downgrade, or cancel subscriptions, download invoices, and receipts, and update credit card details. Developing all of these could take weeks. A second example from client billing: we first launched for our beta group with many functionalities available only via Stripe dashboard and customer portal, and not in Duda’s product. These included: configuring products and prices, hosted checkout, and the customer portal. We created deep links to Stripe for each function, instead of developing a UI in our platform.

3. Think about permissions

Money is a sensitive topic. Most software products with more than one user per account have some permissions mechanism. Think about: Who should see billing and payment information? Who can make actions? How do you verify identity in other channels, such as customer support? Once the free trial is over, can all users upgrade to a paid plan? Who can cancel? Can users see upgrade or downgrade options or locked features even if they don’t see prices? Can they see the plan they are on and not have access to payment info?

4. Be consistent and clear

Another always true advice. Use the same terminology across the entire flow. Remember that your marketing site is also part of the flow, even if managed by the marketing department. Users don’t know it’s two different teams, and they don’t care. IF you are using UI components of your payment processors check the language and design used there and use it within your product.

Give attention to failure scenarios. Payments may fail for multiple reasons and the failure might not be in a system you fully control. For example, a card reported stolen, the payment gateway requires strong authentication and the user fails to provide details, and of course, billing failed charges. Map failure flows, and make them as clear as possible: explain what happened, what are the implications, and what should the user do. Make it clear if the user was charged or not and whether they should try again.

Statement Descriptors

Statement descriptors are the descriptions buyers see in their credit card or bank statements. Make sure it is informative and that users can easily relate it to their purchase or subscription. Unclear statement descriptors are a top reason for users to dispute their charges and for merchants to get chargebacks.

In case your system creates varying charges, consider adding a short description or a reference to an order number to the dynamic part of the descriptor. For example, descriptors like Ben's clothing T-SHIRT or Ben's clothing KMP3W where KMP3W is the order confirmation number will help users to remember they ordered a t-shirt online a few weeks ago, and not contact their bank. This practice is commonly used by airlines and big marketplaces like Amazon.

5. Collaborate with business units from day one

Many times, business units have a lot of knowledge of users’ needs and preferences regarding payments and billing. Sales, support, customer success, and marketing know why people buy, what they ask, and what makes them angry or delighted. It’s better to have these insights and data as early as possible. In addition, these units will be a major factor in delivering any decision you make regarding payments or billing experience.”

Online payments terminology

This section explains some basic concepts. Since the online payments domain is very complicated, I’ve chosen to introduce the basics in a simplified way which is not always totally accurate but does work for our current context.

Merchant: sells goods and services, and gets the money.
Buyer: pays, and gets goods and services.
Payment processor: gets payment method, confirms the payment, transfers money, handles legal (fraud, disputes).
Payment gateway: the technology that encrypts and transmits the payment details from the point of entry to the payment processor.
Merchant account: an escrow account for the merchant under the processor. Holds the funds the buyer pays until they get to the merchant.
Issuer (credit card or payment method): the organization that created the payment method, usually a bank. The issuer pays the processor, confirms payments, and charges the buyer.
Card on file: a state in which the buyer allows the processor to keep credit card details and for the merchant to charge it again in the future, without the buyer having to provide the card details again. Card details are securely saved by the processor, and the merchant gets a token to initiate future payments.

This diagram describes the relations between the different payment entities:

Billing terminology

When dealing with recurring payments, there are a few more terms one should be familiar with:

Product, price, contract: products are the basic entities of billing systems. They represent the recurring products and services offered for purchase. Each product has at least one price and can have more than one, like in the case of a monthly price and an annual price, or one price in US dollars and one price in Euros. Contract is an alternate term for price. Once used with real users, prices are usually immutable, meaning cannot be edited except for naming and labeling changes.
Line item: a combination of price and quantity which results in a sub-total. For example: Basic product manager course $100 x 2, $200.
Frequency or recurrence: the time period for a recurring payment to renew. The most common frequencies are monthly and yearly (aka annual). Other frequencies are daily, weekly, quarterly, or 2-year, 3-year, etc.
Subscription: a set of line items that have the same frequency and are charged together. Each subscription is always related to a specific buyer.
Billing cycle, payment cycle, or billing period: a specific time period for which a subscription is renewed. For example, a monthly subscription with a payment cycle from January 10 to February 10, and then from February 10 to March 10, and so on.
Invoice: in each billing cycle the billing system produces an invoice for each active subscription. The invoice usually contains all the line items of the subscription.
Charge: once an invoice is created and finalized, most billing systems will also try to charge a payment method. The charge might succeed or fail. If it is successful a receipt will be issued. If not, most billing systems have some type of recovery or retry sequence.
Proration: if the line items of a subscription have changed during a billing cycle, most billing systems will automatically charge the relative amount based on the ratio between the date of change and the billing cycle. For example, upgrading from a $10/m subscription to a $15/m on the 15th of the month, with a billing cycle that starts on the 10th of the month, will result in a $14.16 invoice at the end of the cycle. The invoice will contain two line items: $10/m x 5 days = $1.66, $15/m x 25 days = $12.5.
Billing schemes: use in advanced billing situations, mostly when the amount of service supplied each billing cycle is changing. Including tiered pricing (aka volume discount), usage-based pricing, and more.

This diagram describes the relations between the different billing entities:

My problem with RimWorld and the game I’m trying to make

yonatan.shaham@duda.co (Yonatan Shaham) — Sat, 25 Jun 2022 08:04:50 GMT

This week I installed and played RimWorld again. I decided to give it another shot after I was disappointed in the past. I enjoyed it for an hour and a half or so, and then I felt I don’t want to play anymore. This was the same experience I had two times in the past. In this post, I try to explain why I feel a problem with RimWorld, and how it related to the game I’m trying to create for a while now, with little success.

RimWorld problem #1: too much content

RimWorld has endless content: colonists’ traits, colonists’ needs, room characteristics, weapon types, resource types, outdoor elements, animals, terrains, construction elements, events, and enemies. But the mechanisms of the games are numerous. The first is the cycle of the need: colonists have needs, and if needs are not met they may die or have a mental breakdown, the player can prioritize which actions they will do, some actions will satisfy the needs to some level, satisfying needs also requires resources, with time, new needs arise, and so on. This mechanism can run with two needs or two hundred needs. For me, it feels the same. Other mechanisms are research which allows more actions to be done by the colonists, trading with foreigners, fighting foreigners, and special events (aka the narrator).

This creates a vast amount of content, but for me, it’s not interesting. After about an hour, when I finally can cut my crops and have the colonists eat fresh food, it starts to feel daunting. I know that after twenty minutes they will start to be unhappy because they only eat vegetables, and want meat, and then cooked meat, and then drugs. And after I made them rooms with beds, they say the room is ugly, or cold, or whatever.

When I was in my PhD studies I was developing geo-simulations for academic studies. I have a lot in common with developing games like RimWorld which are basically simulations. One day, my advisor, Itzhak Benenson, responded to my suggestion of randomizing the fire risk parameters of different buildings. My idea was to create a more “realistic” simulation by adding noise. Benenson told me: that adding randomization to the model usually does not change the model behavior, only adds variance.

I think it’s the same for me in the case of such games like RimWorld. Having many types of things that revolve around the same behavior does not interest me a lot once I figured out the core mechanism. It does not mean it’s inherently bad, just boring for me.

RimWorld problem #2: controls and situational awareness are difficult and consume the player’s energy

During most RimWorld gameplay, the player does not have direct control over the colonists. Most control is done by specifying which works each colonist would do. In advanced mode, the player can also set priorities. This is a very interesting control mechanism, but it has a big side effect: it is hard to understand what exactly made each colonist do what they do right now. Add to this the fact that UI is heavily text-based, the player needs to read a lot to get information. And on top, the vast amount of content.

This side effect which is enhanced by these two game choices results in the player investing really a lot of energy just in understanding how to make the colonists do something, or why they are not doing it. You can say that this is part of the game and what makes it unique. That’s of course totally legit, it just does not work for me.

I must say that games with some level of unclarity really interest me. But I think RimWorld takes unclarity to a place I don’t like. As I see it the unclarity in RimWorld is tactical. It is about having situational awareness, and about having exact controls. I prefer unclarity on the strategic level, unclarity about what other players and NPCs are doing or about to do, and about the results of my actions when they entangle other players’ and NPCs’ actions.

RimWorld problem #3: information is too explicit

This one might sound contradictory to the previous problem, but it isn’t. The previous problem is that information is hard to find. This one is that information is too explicit. Colonists’ needs are expressed in a way that does not require the player to think what is the solution, like ‘eat without a table’. So you need to build a table.

The side effect is that the player gets a view of what they need to achieve to solve problems for quite a long time into the future. The main challenge is not coming up with a solution to a problem, but managing the way to get to the solution. And this management is hard mostly because (A) the controls are hard, and (B) there are always more problems than resources to solve them.

For me, each time I played, felt like “strategy-grinding” after about an hour. I know many people like this, but I don’t. I want more focus on the challenge of understanding what are the solutions to the problems the game presents.

What I do like? the “Tycoon” effect

One thing a really like about RimWorld is what I call the “Tycoon Effect”, following the many “Tycoon” games. By Tycoon Effect, I mean a gameplay experience in which the player creates their own system, this system has a unique history originating from the gameplay (many times it includes naming parts of the system, and this history is reflecting the way and paths the player took to overcoming challenges.

When I was playing Railroad Tycoon I (the best game ever in my opinion), there was a feature that allowed you to replay the development of each railroad network throughout the game up to the current point. I could do this again and again. Watching the history of my gameplay replayed reminded me of all the experiences I had, all the challenges, and how I overcome them. The solutions I came up with, good or worse, were reflected in the network development.

How does all of this relate to the games I’m trying to create?

For over a year I’m trying to create a game that will reflect in a way that I find interesting strategic decision-making. I started a few games which I decided not to finish for different reasons: The Gang and Co. Trading Company , You can build a trade route , Taxi , Medieval Trader , Maritime Trader .

I want strategic decision-making to emerge from the uncertainty of the other actors’ actions. The themes that interest me are economic ones, as opposed to war, action, etc. It’s not that I don’t like action games, I have a lot of hours of Dall of Duty multiplayer. Even then, I like the interaction between players and not the single-player interaction with the campaign mode.

In many of my game trials, I’m interested in feedback loop aspects of trade and economic activity. This goes back to a visit to New York City Museum when I saw an exhibition on forming the Atlantic trade route between New York and London. It explained how trade sky-rocketed grew when traders started to announce regular travels across the Atlantic instead of the ship owner looking for goods to buy and sailing only when they have enough. This, combined with the too-simple action in many Euro games of ‘building a trade route’ was the motivation behind many of my game ideas.

Last, I’m more interested in games where the mechanism creates the essence of the gameplay, versus vast amounts of content or lore. It goes back to my PhD study days, and to my general interest in systems.

I feel RimWorld goes the other way, making controls difficult and information gathering strenuous. Making the tactic difficult instead of strategy.

I’m not sure what I’m going to do next. I feel that the better game demos I created had less content, which created a tightened game loop faster. Faster for me as a creator, and faster for the player. The Taxi game is probably the best so far. Maybe I should first create abstract mechanisms, and only then add some lore, even non-realistic. I think I already have an idea.

Designing basic UX for the maritime trader game

yonatan.shaham@duda.co (Yonatan Shaham) — Sat, 18 Jun 2022 13:43:24 GMT

Last time I came to the conclusion that without UX improvements, my game is not playable , this is not a minimal playable game in any sort of way. Today, I made a fast iteration to bring the game UX to the level I can test it with users.

Product, design, or coding: Always start with the big picture

Any design, development, to product management work, should always start with the big picture. Spending a lot of time and effort on the details of some feature, important as this feature may be, is almost guaranteed to become a waste of time, as you find out it does not fit with the bigger image.

I started with a high-level pen and paper sketch (see image). First, I thought to represent boat inventory with crates, and places for crates. Then, I thought to have some human figure represent the boat crew, with hunger and food-related info. Regarding money, I thought to have a sign on the boat with buy price info but did not have a clear idea of how to visualize it.

Speed up delivery time: reuse what you can

For me, the hands-on process of designing UX/UI in Unity is always much more time-consuming than the code and movements. So I try to reuse as much as I can UI elements and UX concepts that have proven to work well in previous games I made. Reducing delivery time towards a working software is something that you should always do. This is basically the number one tip for indie game developers.

I used a slider to represent increasing hunger. I also used a common convention of having a resource with a number at the corner to represent the food inventory, money, and the carte buy price. I did have one innovation, instead of having a hunger slider based on color with a ‘Hunger’ label next to it, I found an icon that can represent hunger, and made the slider fill it with time.

New Paragraph

Closing the loop and thinking about UX

yonatan.shaham@duda.co (Yonatan Shaham) — Fri, 17 Jun 2022 13:02:46 GMT

I worked about two more hours on the game. I closed the basic game loop and made some decisions about it. When I started , it was not clear to me exactly how the loop ends. I started working by copying code snippets from the Taxi game to recreate its core game mechanic:

People march in from of the taxi or boat and react to the price.
In the taxi case, if the taxi fare is lower than the fare the person is willing to pay, they take a set.
In the boat case, if the buy price is higher than the price the person is demanding, they sell their goods.

Coming up with a win condition

The loss condition was already clear to me: if you run out of food you lose. Some would say this is a common theme in my games . But the win condition was not clear to me when I started. I had a vague idea that when the player has enough goods they can decide to set sail. To keep things simple, I added a cap for the boat inventory. Once the boat is full, the player sets sail automatically. In the future, I might use this to allow upgrading the boat to hold more inventory. I added a lose scene with just the text “No food”, and a similar temporary win scene with the text “Sailing”.

You can see the game in action in this video (rendering is a bit jumping due to screen recorder):

Product management aspects

As I noted in the previous post, my goal is to get feedback as soon as possible, on a piece of working software. So now I have a working software, can I get feedback? I think that at this point it is very clear that the game UX is horrible. You can’t understand what’s going on. It is hard even for me. So I guess I don’t need to show this to a user or a player in order to know that improving the UX is the next step.

Product management principles in practice: indie game development

yonatan.shaham@duda.co (Yonatan Shaham) — Thu, 16 Jun 2022 05:53:19 GMT

Two days ago, I worked on my new game idea for 60 minutes. In those 60 minutes, I put some key product management, lean, and agile principles into work.

Push for early validation of assumptions

Product managers should push to validate assumptions as soon as possible and focus on the risky ones. Validating assumptions quickly is the thing that allows us to make informed decisions on whether we should pivot or persevere.

In the case of games, the riskiest assumption is always the same: "This game is fun to play." Fun is the core 'business value' of games. Even though fun is very hard to theorize, it is very easy to notice when people are having fun. So as a product manager or indie game developer, the first thing you want to aim at is having the game equivalent of a minimal viable product, a Minimal Playable Game (a term I just made up). Basically, it means you want to express the game mechanics and loops and let some people toy with it.

I started to work on the inner game loop :

Wait for new traders to come
Trade with those who can accept your prices
Adjust prices
With time, consume food
Replenish food stocks

Within these 60 minutes, I managed to develop the very basic code of (4) with time, consume food, (5) replenish food stocks and pay for food. Next, I will move to the other items. My plan is to reuse most of the code of the Taxi game .

Deliver a working software

When developing, I plugged in stubs and placeholders to all features and UI components as much as possible. I did not stall on any detail and pushed to close the loop as fast as possible, delaying many decisions for later. Some examples:

All UI elements are plain texts at the top bar (see image).
I used MS paint to create a background that reflects the general layout of the scene. I might replace that later with better graphics.
I did not care about the numeric value of parameters such as food consumption rate and food price. I just verified that they are in values which makes it easy to see their impact in play, for example, food reduces every 2 minutes so I can easily notice it changes only on even minutes, and food price is 0.5, so money changes are noticeable. I will find the right values when I move into the balancing phase.
Since I did not decide on UI, I mapped the keyboard to the only player action that I have now and set it to work only in the editor. I created a special method in the code for that and named it PlayTestingInEditor() , so I’m clear this code is not relevant for the real game. This code allows me to test the functionality as a working software immediately, without dependency in any UI or input decisions I will make later.

Get feedback early

This way, I move very quickly toward working game mechanics that can be tested and that users can give feedback on. Getting user feedback as early as possible is a key principle in product management. It is the best way to accelerate the build-measure-learn loop.

The first user is you. Try the play the very basic loops and see if you like it. Don’t invest too much in any local aspect like art, sound, animation, or a variety of content. Then, test with empathic users like your friends, for whom you can bridge the gap of the features you did not yet develop through oral explanations. It is true that you don’t need more than 5 users for every user testing round.

After 60 minutes of work, I have probably completed one-third of the work needed to test the inner game loop. Meaning I can get user feedback just by working 2 more hours (just need to find the time for that…)

Why do things this way? Can’t I just work another 60 minutes?

When developing a new product, games included, the scarcest resource is time, calendar time. You are facing extreme uncertainty about your users and your market. Each bit of other resources like developers’ time or money you spend on the wrong users, the wrong market, or the wrong feature, cannot be recovered. Get to a point you can validate or disqualify your hypotheses and assumptions as soon as possible. The best way to do it is to always push for working software, focus on end-to-end user paths and core feature functionality, and go out there to meet users. For sixty minutes or for 60 days, the same principles should apply.

Taxi + Trader Roguelike = New Game

yonatan.shaham@duda.co (Yonatan Shaham) — Mon, 13 Jun 2022 16:10:48 GMT

I did not write about game development for a while, because I did not really do anything about it. But in the recent days, I started to toy with the idea of connecting two games I’ve developed previously to a demo level: the trader roguelike on which I wrote here many times, and the Taxi Tycoon game.

Both games originate from my interest in doing some other type of business game, and therefore they have a lot in common. At least in the way I perceive them.

How should I combine the two games?

My idea is to take the Taxi mechanics of waiting for passengers to flow and adjust prices, and replace it with the village scene from the trader roguelike and locate it on a pier with a boat instead of a taxi, and marching traders instead of passengers. From the trader roguelike to take the food consumption on the way, the exploration of new places, and the price differences.

I’ve made a very high-level sketch of the UI of both scenes.

Core game mechanics: nested game loops

I plan to have two main game loops, nested into one another. The inner loop would be the pier scene, and would work very much like the current Taxi game:

Wait for new traders to come
Trade with those who can accept your prices
Adjust prices
With time, consume food
Replenish food stocks

The outer loop would express the economic effects of the trade:

Make deals in a town
With time, people get richer
The prices they are willing to trade will increase, both for selling and for buying
Food costs will increase as well

In such a structure, the outer loop balances the inner loop.

Product manager resume: top 3 mistakes

yonatan.shaham@duda.co (Yonatan Shaham) — Thu, 19 May 2022 05:19:33 GMT

As a hiring manager participating in the hiring process of product managers at Duda, I have read hundreds of product manager resumes and interviewed dozens. It is true what they say, it takes me less than five seconds to decide if a resume is worth reading in detail or rejecting immediately. I have noticed 3 key mistakes many product managers make which are likely to lead them to the rejected pile, and I would like to share them with you so you can avoid them.

This post is mostly for product managers with some experience looking for a new position but can be relevant also for those looking for their first product management position.

Key takeaways for writing a product manager resume

Spell out the activities you did
Clarify in which the type of companies, products, and teams you engaged with
List your achievements

Spell out activities you did as a product manager

Product management is a highly collaborative work type, where your influence is mostly indirect. You don’t deploy code or create pixel-perfect designs, you influence many teams to eventually move the needle. But as a hiring manager, the question I as myself is “Should I hire this person?” not “Should I hire that product team?” Therefore, y our resume needs to make it clear to me what did you personally do in your product positions.

Write down explicitly the activities you did hands-on , and clarify which of them you led and in which you participated, for example: writing PRDs and handing them over to a dev team, analyzing support tickets, conduction user interviews and research, developing product metrics and tracking them in Mixpanel, demoing to sales people, scoping MVPs, managing backlog.

As a hiring product manager, I will use these to verify that you have the hands-on experience and skill that I’m looking for, given the specifics of the open position.

Clarify companies, products, and teams you engaged with

If I’m hiring for a product manager position in a SaaS B2B company in the digital marketing domain working with agile methods like scrum where each squad is led by a product manager and a developer, I will try to understand if candidates have experience in any of these domains, work methods or types of organizations. Don’t let my Google your past workplaces to find out. Write it down in your resume. Also, link or specify company websites.

Add information about the types or domains of products you worked on. Especially if you worked in a larger company that offers multiple products, or that you personally worked on features that are not part of the publicly know product of your company.

Last, let me understand the organizational settings of your past positions. Did you work in squads ? With multiple development teams?

For example, I would write down the following:

Product manager, Duda

2018-2021

B2B2C SaaS Website builder ( duda.co ). Co-leading a squad with a dev lead.

Product under personal responsibility: App Store, payments and billing.

List your achievements

Product managers should work to move the needle, to achieve impact on business metrics. As a hiring product manager, I’m looking for people who know that that’s what they need to do, and that have made it.

Write down explicitly how you made an impact in each one of your positions. Don't let me think you achieved nothing. Don’t be shy and don’t hide it. Sure, don’t take credit for achievements that are not yours. Specify numbers as much as you can.

You might struggle at first with this, so here are some examples, mostly for junior product managers:

Improve funnel performance
Reduce support tickets around a specific topic
Shipping product, especially large or complex
Productizing manual processes
Reducing churn of a feature
Plan and execute A/B test

A difference of night and day

yonatan.shaham@duda.co (Yonatan Shaham) — Sat, 07 May 2022 12:21:11 GMT

I did not post a lot in the last few days, partly because I was swept by work. I did have a lot of thoughts on the game, and applied many changes.

The first thought that I started to run with, emerged a week ago. I realized that I've been too fixed on the notion that the game experience should be pretty much the same in all game phases. I think that the success of open world game like Minecraft and GTA/RDD, combined with the general way strategy games work, biased me towards the thought that as a game maker I should create some game mechanics and probably some work generation procedures, and that these should create the entire game (I think Magic Survival is a great example to this type of games.)

I tended to avoid 'directing' game level, or creating more than minimal content to my games, as I somewhat felt that I don't want to create a game that is mostly based on going through some content flow. It also has a lot to do with my short academic career , when I built simulations of natural and social phenomena. I wanted my game to be a bit like simulations.

So I decided that for start, the game should behave differently when the player is in the village, and when travelling in the roads. This change also responded to one of the issues I had with the game: that time did progress when the player moves inside the villages at the same rate it would progress when moving between them. This was highly unrealistic.

I created two game modes: Village and Travel . When in the village mode, the camera is focused on the village area. Player movements do not progress time (remember the game has Roguelike movement). When the player move out of the village, the game prompts them that they will get hungry when travelling, and that hunger will hurt their health. The player can leave the village or stay. This prompt also solves the problem of introducing the hunger and health mechanisms to the player.

This change in time behavior led to my second main game addition: night and day experience. I learnt how to add lights to Unity 2D games, and created a global light for the sun, light in the village, and a lamp the player holds. Next, I adjusted the time scale so travelling between the two villages will take about 24 hours. This time scale makes much more sense, and users will probably understand why they should eat 3 times if they want to complete their journey. Lastly, I calculated sun light colors based on Sun Photo Calculator and the simulated hour of the day.

Now the game has a completely new experience, and I'm intrigued to see how users will react.

Mouse movements, testing

yonatan.shaham@duda.co (Yonatan Shaham) — Mon, 02 May 2022 18:15:22 GMT

Following the user-testing , I changed the movement controls from WASD to mouse. the user points with the mouse and right clicks to set a destination. Once clicked, the avatar progress to the destination without stopping. This was not my initial intention, but a result of some logic from the WASD code. By I decided to keep is as it manifests the roguelike nature that once the player makes a decision they cannot change their mind and needs to face the consequences.

I also started to work on testing. The reason for starting to add tests now is that I got to a point I have a simple working game, so I can decide to freeze the development of some game mechanics. A few months ago, I used this video guide by Infallible Code. I also recommend this comprehensive Udemy course to learn about planning and designing tests in general.

UX improvements, user testing

yonatan.shaham@duda.co (Yonatan Shaham) — Fri, 29 Apr 2022 16:39:33 GMT

Today I focused on user experience (UX) improvements.

The first improvement originated from quick user testing I did earlier this week: a user expected to see something on the screen around the player avatar when they buy or sell something. They offered an animation of popping coins. This type of animation is very excepted in games these days.

So I created a simple animation each time the player makes a transaction:

When the player buys a resource, a coin drops down and the resource pops up.
When the player sell a resource, a coin pops up and the resource drops down.

The second is adding sound effects. Until now there was only one sound effect of moving around, with a sound of foot steps.

Sound effects are extremely important for game user-experience, as they significantly increase the fill of the player that their actions (inputs) result in real consequences (outputs) in the game world.

I added sound effect for:

Selling
Buying
Eating

For the eating sound a chose a very prominent chowing sound. It helps the player understand the importance of eating and food management in the game.

I also did quick user testing. You can never over estimate the importance of user testing when developing something. Do as many as you can and as often as you can.

The user testing took 3 minutes and yielded two important insights:

The WASD control s are not comfortable for some users. Try to make mouse controls for moving.
Users don't understand that the fragmented road is a road, so they don't look for the other village at the end of it. I tried to create a worn road, so it can be upgraded later. Need to make a continues road.

Graphic UI

yonatan.shaham@duda.co (Yonatan Shaham) — Thu, 28 Apr 2022 18:09:58 GMT

I created a new UI, based on icons instead of text.

Drag to compare:

We have a game loop

yonatan.shaham@duda.co (Yonatan Shaham) — Wed, 27 Apr 2022 19:43:18 GMT

In the last few days I did not have the chance to write something.

I did complete a working game prototype with a complete game loop:

The player moves around the world on a grid, and can explore it at will.
Player movement advances time.
The player can buy or sell cloth at villages at different prices. Buying at a low price and selling at a high price is the way to make money.
With time, player gets hungry. High hunger levels reduce health.
Health automatically restores when hunger levels are low.
The player can purchase food at one of the villages.
The player can purchase a wheeled cart that reduced hunger buildup, as physical effort is reduced. The cart is expensive.
The player wins when the amount of money is 50.

The next steps would be:

Replacing the text UI with graphic UI elements.
Adding analytics.

Starting trader rougelike

yonatan.shaham@duda.co (Yonatan Shaham) — Sun, 24 Apr 2022 17:40:04 GMT

I started developing the game. Currently the best way to describe it is a trader roguelike :

The player moves on a grid, and time progresses only when the player moves.
The player can buy and sell items, of a single type.
Prices are different across the map.
As time progresses, the player get hungry, and when hungry enough the health starts to diminish.
The player can buy food at the food store and eat it.

I made this quite quickly, as I reused a lot of code and concepts from previous games I tried to develop.

Also, the UI is very bad.

A video of what's currently working:

Starting to post daily about game making

yonatan.shaham@duda.co (Yonatan Shaham) — Sat, 23 Apr 2022 16:36:07 GMT

I decided to post more frequently on my game development journey.

You can expect that these post will be somewhat fragmented and associative.

Yesterday I got to think again on my want to build a game about trade rout formation. I've written about this before and even developed a prototype , but it did not go well.

I decided to do some more detailed historical research to get inspiration. I started with looking for content on the economy of the wild west, because my previous attempts were wild west themed ( The Gang & Co. Trading Company , You Can Build a Trade Rout e ). But I did not find anything good enough.

I decided to go back to study the period that originated my motivation in creating a game about trade route formation: the late medieval / early modern period. My original motivation was that many strategy games, board or video, allowed a player action "You can build a trade route" without any additional complications.

But building or establishing a trade route is a complex endeavor. Many people take part in various activities, out of which a trade route emerges. The is no object which is the trade route, but the repeating activities of people of trading again and again on the same route.

I started to form a new idea about the game: a person moving between settlements, transferring one type of goods - clothing and fabrics, lending money to buy goods, and having bad encounters on the road.

I looks a lot more like Trade RPG than anything else I've done previously. Looks interesting. I think to start with Kenny's medieval RTS kit .

Product manager: be a professional, not an artist.

yonatan.shaham@duda.co (Yonatan Shaham) — Fri, 25 Feb 2022 11:14:44 GMT

Key takeaways

Product managers are often expected to be "wizards", demonstrating some hidden thinking capacities.
Product managers should be expected to be professionals.
Being professional means holding professional knowledge. Knowledge that can be explained to others when needed.
Being a professional product person means creating decision making processes that are understandable to all stakeholders, who in turn can follow the reasoning leading to the decision (not necessarily agree with it).

Moving the needle as a wizard

There is a common notion among product managers, in particular during the early stages of their PM career: that they should perform their job like wizards or artists. What do I mean by “like wizards or artists”? When you look into most PM job training materials like online courses, blogs, podcasts, etc., you keep hearing that the PM should move the needle , make an impact, prioritize, and even the now-notorious metaphor “ be the CEO of their team ”.

All these may, and often do, create the impression that the PM should be the sole person doing these activities of decision-making. This was my exact impression early in my PM career. I believed that most of the people I work with, my team, my supervisors, other stakeholders, have the same expectations people from me: that I will do many activities to gather information, go to my ‘drawing board’ or ‘put my thinking cap on’, then call everyone and tell them “I thought about this a lot and this is what we are going to do”. Not only that, but also that my decision will be some sparks of insights which will probably know them of their metaphorical feet and will make them say (probably only to themselves) “how come we did not think about this?”

This is what I mean by “like wizards or artists”. Same as when you see the work of a great artist you are struck with an epiphany. Or being overwhelmed by the mysterious wisdom of the wizard.

With time, I came to think in a very different way, that product managers should be treated as, and see their own work, as the work of a professional. As a group PM, I found that communicating this view to my product managers is very important.

Who is a professional?

Say your want to buy an air conditioner for your home. You invite an air conditioning specialist to advise you on the right model, to sell it to you, and install it. They arrive, walk around the house, ask you some questions, and after a while say: “You need a unit of 5000 [BTU](https://en.wikipedia.org/wiki/British_thermal_unit). I will install it on this window. It costs $270. I can have it for you by Thursday.”

Consider another scenario. After asking their questions and walking around, the air conditioning specialist tells you: “You have 3 options. A small window unit of 3000 BTU which costs $150. This is probably too small for you as your apartment is facing south and gets a lot of sun in the summer. You might have seen such units at your neighbor, but their apartment is facing north, getting less direct sun. I recommend a 5000 BTU unit for $270. Because the other rooms of your apartment don’t face south, it will produce enough cooling power to make the entire place comfortable, but not cold. If you want to have your entire apartment cold in the summer you would need a central unit. The benefit of a window unit is that in case it does not cool enough for your taste, you can easily replace it because the installation is simple. Installing a central unit requires opening the ceiling and building air vents, then closing them with drywall. The total cost is around $600.”

Who would you consider the more professional? You probably guessed that in my opinion, it is the second person.

What is a profession?

Professions are thought and learned. Indeed, people differ a lot in their skills and abilities. Nevertheless, most people can grasp some professional knowledge applied to a concrete context, if it is explained in a manner that fits their prior knowledge, skills, and abilities. In the second example, you were able to understand the specialist's implementation of professional knowledge in context. This won’t make you a professional, you probably won’t go now and advise your friends on their air conditioning needs.

An important aspect of interacting with professionals is that you know how to continue the conversation about the implementation of their profession to the context. For example, you might follow up and ask “Supposed I take the 5000 BTU unit, and later decide I want to the central unit. Is there a market for such used units? Or did I throw away $270?” Such conversation allows making the most of the interaction with a professional.

The above cannot be said about arts. It is true that one can study art. But making art is essentially about the artist as a person. It is also true that people might be bringing a lot of themselves into their professional practice, and that some of it is very hard to learn, teach, or converse about. However, you won’t expect to have a follow-up question similar to the one above about air conditioning with an artist about their art. You also would not expect the wizard to reveal their magic.

Product managers as professionals

After some time as a PM I was thinking: what would it be like if I had in my team a position for each profession? If there were a designer, a data analyst, a scrum master who manages Jira (the software I hate the most) and scrum ceremonies, a tech lead who oversees all estimates and execution, QA who makes sure all work matches the requirements, a product marketing function who works with sales, marketing and support to communicate product releases. In such a case, what would I do as a product manager?

In many cases, PMs do some of these tasks, and they are part of their job description. But it is clear that at least in principle, they can be assigned to others with specific professions, which means they are not the essence of the product management profession. So what is?

What is clearly left for a product manager to do is to write down requirements and their priorities. But is the PM expected to be the source or origin of the requirements and priorities? Is the product manager responsible to make the decision about these? I argue not. As I see it, product managers should be responsible for the process which results in decisions on requirements and priorities. The responsibility is first and foremost for the process, the opposite of just coming up and saying “do this, and now”.

How is all of this relate to the meaning of ‘professional’ I discussed? I said that being able to communicate the professional knowledge in context is the telling sign of professionalism. When done in the best way, good processes result in decisions that make sense to all participants. A decision that might bear risks, be based on assumptions, and even be a leap of faith. And yet is understandable to all stakeholders who can follow the reasoning leading to the decision. This is exactly the result of the work of a professional decision-maker, the product manager.

Following this line of thought, I moved to focus more on managing the process of decision-making on the things my team should do. A key part of this is simply communicating effectively and facilitating communication between stakeholders to create an agreed unified view of the matter at hand. It also requires bringing in relevant methods for decision-making and prioritization and applying them correctly. This also needs to be communicated.

Last is making a decision. In some cases, a good process leads to a clear decision everyone understands and supports. In other cases, there are some viable options and a judgment call is required. When this is the case, sometimes I make the decision and know that even if others don’t agree they understand why I decided this way. In other cases, when I think that such a judgment call is above my rank, I pass it upwards.

This is the opposite of going to my ‘drawing board’ or ‘put my thinking cap on’, then call everyone and tell them “I thought about this a lot, and this is what we are going to do”. Being a professional and not an artist or a wizard. I strongly urge you as a product manager to ask to be treated this way, and not to be expected to pull rabbits out for your hat.

Validating a game idea using a text-based adventure

yonatan.shaham@duda.co (Yonatan Shaham) — Sat, 18 Dec 2021 13:54:02 GMT

Three weeks ago I published the first version of "You can establish a trade route". It was a short text adventure. The plater is presented with a short text and an image and can choose their next action.

My goals in this version were:

Validating decision model
Validating the theme
Creating some content for future versions

Being stuck

I've been trying to work on this game for a while now. Each time I would start wireframing some UI or even start coding. And each time I got the feeling that it's not really clear to me what exactly am I doing.

At some point, I watched a video by Jonas Tyroller titled How to design a decision . I liked the analytic approach to designing the player decision, so I set down to specify the core decisions the player would face in my game:

Freedom - what can the player do?

Travel or stay
Buy food (in future versions: buy equipment and properties)
Negotiate deals and prices

Impact - what are the results of the player actions?

Get and spend money
Create demand for trade
In future versions: change prices, equipment and property have impacts

Understanding - what does the player understand about the meaning of their actions?

Money and inventory demand if the player wins or loses. Not enough money means losing.
Demand is affected by the player's reputation as a treader.

Challenge - what should the player find out during playing and overcome?

Waiting in a town allows to collect more goods and make more money but also costs money

I then realized a few things. First, in order to validate this model, I don't need to have the UX, UI, and code of the full game. I only need to implement this decision model in some game mechanics, and the fastest implementation will enable me the fastest validation.

Second, that it might be that my can will be made of several parts, each in its own genre and own code. High-budget titles back different genres into the same code and engine, but it's not a must for me.

What does validation mean?

My day job is as a product manager, and product validation is a great deal of a product manager’s work. Usually, it is made of verifying with real users that two statements are true:

People do have this problem or need, which we aim to solve, to a degree they are willing to do something about it (in most cases: pay).
Our product can solve this problem or need.

The first is also known as Market Risk and the latter as Product risk.

An interesting book recently recommended to me by a colleague, The Mom Test , strongly argues that for games, only the product risk matters:

Video games are pure product risk. What sort of question could you ask to validate your game idea? “Do you like having fun? Would you like to have even more fun?” Practically 100% of the risk is in the product and almost none is in the customer. You know people buy games. If yours is good and you can find a way to make them notice it, they’ll buy it. (p. 54)

So how to validate a video game? I decided to combine two notions: the first is a well-known game design principle stipulating that “All the best games are easy to learn and difficult to master”, also known as Bushnell's Law or Nolan's Law . The second notion comes from classic product management thinking: the best metric for product value is retention. If people come again and again to use your product it means it solves a problem for them.

Combining both, I drew the following:

�� If people find the game both interesting and easy to learn - hard to master, we should expect them to lose a few times and try again.

If they don’t lose it means the game is not hard to master. If the game is not easy to learn they won’t understand how the game works and won’t have a general or vague notion of why they lost, thus no motivation to try again. Last, if the general experience is not appealing, they won’t try again.

Implementation

So I wrote down a script and specified the decision points and made sure they demonstrate my decision model.

Then I quickly created a text-based adventure. It was a very bad code. Not scalable, hard to maintain and test. But I knew I don't need anything more than that as it was made only to hold this very specific script.

Overall, end to end, the game takes about a minute to complete (it is a very short script). You can either lose the game or win it and get a score between 1-5.

The reason I developed from scratch in Unity and did not use a text-based engine like Twine is that I wanted to implement a strong analytics platform I am familiar with, namely Mixpanel. Since my goal was to validate, I needed to analyze player actions in a deep way.

A Windows version of this version is available on itch.io .

Results

A total of 37 users played the game. Out of them, 27 (73%) played the game more than 3 times, and 11 (30%) people played it more than 5 times.

Out of the 37, 17 (45%) won the game. Out of these, 5 (41%) won the game more than once.

Conclusion

For me, these numbers were a positive result. They demonstrated that a big enough portion of the player lose and want to try again. Of course, these are small numbers, but they are enough for some validation. If only a few people were willing to play again after losing, it surely meant the game is either not easy to learn and hard to master, or just not interesting.

So I moved to create the next version of the game, now available on the game page on itch.io . The second version starts with a similar text-based adventure and then moves to a map-based (slightly) open-world style.

Part two: Product presentation and meeting tips (Brainstorming does not work)

yonatan.shaham@duda.co (Yonatan Shaham) — Sun, 13 Dec 2020 10:05:21 GMT

This is the second post about presentations. You can read the first one in case you missed it.

Present in a way that tells a story and gives required background

When you present the goals, expectations, and subject matter in a good way, people can quickly connect and contribute. If your presentation is unorganized, people will have a hard time trying to respond. I pretty much hate the term ‘storytelling’ even though people often tell me I’m good at it. I prefer to think of a good presentation as a well-structured argument. Start with premises, the things everyone should know and agree upon to start the conversation.

Give background and context

Don’t assume people know the details or are familiar with the background, even if you’ve discussed it with them in the past. Each person’s mind is focused on things that matter to them, not on those that you deal with on a daily basis. Make sure to remind everyone of the relevant history, past decisions and their reasons, and the long term vision. Even if it feels that you’ve said it a dozen times before already to each person separately.

Clearly repeat the definition of specific terminology, jargon, and formulas and make sure everyone understands them. Do this in a welcoming way. Asking ‘Do you have any questions?’ or ‘Does anyone understand?’ does not encourage many people with a more introverted personality to speak up. Saying something like ‘this is a unique terminology that may not be familiar to you’, ‘this formula might be not intuitive’, or ‘this is a complex process that I often need to explain in details’ makes people not see themselves as limited and failing to understand, but as facing with a task that it is legitimate to ask help for.

Ultimately, if you ask for the help of others, it’s your responsibility to make sure they understand. There was a time that I used to feel I just can’t repeat myself five times on the same topic, each time with a different group of people, so I just assumed everyone has the same knowledge and background. Many times I felt I don’t want to hear myself saying the same things one more time or that I was trying to save five minutes at the beginning of the meeting. turned out in almost every case to me answering very basic questions thirty minutes after the meeting kicked off. Meaning that until then the meeting was a waste of time for the person asking that question, as they missed some key knowledge, and I did not make sure to give it to them.

Follow a logical order

The best method I have for that is to move forward instead of backward when planning the presentation. I lay down the background and ask myself ‘If I had no additional knowledge, what would I need to know next to be able to contribute as a participant?’ Then I go to prepare the next section to answer that question. It does not need to be a well-designed deck of slides. You can also share a document with bullet points, or have your private document to look at when you talk.

Working forward helps you is several ways:

It makes sure you give the right background and don’t jump past important information.
It makes it easier for the audience to follow.
It helps you to figure out whether you are trying to cover too much. If you see that you need to build a 30 slides deck for a 20 minutes call, you should probably rethink the scope and goals of the call, and consider making it longer or having a followup call.

Human interaction in groups is important and can be done only when everyone is present, give it time

This point might seem to you as the opposite of what I’ve written so far. Indeed, making a meeting productive and meaningful requires planning, scoping and leading. Putting people in a room and ‘letting them talk’ is a guaranteed recipe for wasting everyone's time. But it does not mean that every moment people don’t follow the plan is a waste of time.

Human interaction is not linear and has to go through detours and unexpected areas in order to be meaningful. If we did not need live human interaction we wouldn’t have any reasons to have meetings (needless to say, many meetings could have been emails, we all saw it during the first few weeks of COVID). When you decide to have a meeting, allow it to evolve in the ways human interaction takes, at least for some minutes in every one of the sections you have planned. People have many types of needs: to hear themselves, to be listened to, to listen to others, to find out that others think the same about certain things or that others don’t understand the same things. Allow people to interact for a while to fulfill those needs. Work is not only about getting things done.

Wrap up clearly and set follow up

A group of people just invested their time in what you need. Make sure you communicate to them what the meeting has managed to achieve. If you were to get their feedback, repeat the main points and explain what you are going to do with it. If you were to get agreement, state that the agreement was achieved and its contents.

Say what’s next: what people should expect to happen? When they will hear from you next? Do the participants need to do something else, like emailing you with their thoughts or introducing a new person into the process? Say all these things at the end of the meeting, and if needed also send them in writing.

You can cancel meetings

If the meeting is getting close, and you sense unclarity regarding the goals of the meeting and what it is that you are looking to get out of it, consider cancelling it or pushing it to a later date.

It is quite self disappointing to go out of a meeting you owned and think that you wasted everyone’s time. In most cases, people won’t be angry with you if you tell them a meeting won’t happen. They have their own work to do and will appreciate it if you free up an hour of their time.

Product presentation and meeting tips (Brainstorming does not work)

yonatan.shaham@duda.co (Yonatan Shaham) — Mon, 23 Nov 2020 15:05:51 GMT

As a product manager, you do a lot of presentations: to your fellow product managers, your squad, customer success, sales, marketing, and others. Looking at my calendar, I do one to three presentations each week. Not all of them are called ‘Presentation’, yet all of them share the notion of me presenting some content to the other participants and them responding in some way.

Over the years I’ve come to realize that these meetings can be optimized. Meetings consume a lot of time, instead of a single person they involve a group, and every moment the meeting is not relevant to some of its participants is a waste of time and energy. I can bet that you and others within your organization would agree with the statement ‘we have too many meetings and some are a waste of time.’ You can do better.

Preamble: Brainstorming does not work

The concept and technique of brainstorming originate in the 1930s and has been popular since the 1950s. In those days, people in the lower ranks of the organizational hierarchy did not express freely in front of higher ranks, wary of having their ideas judged by higher ranks. To overcome that, a method and a time unit in which ideas can be brought up while postponing judgment was created. Later, ideas were judged and decisions were taken, yet participants were acknowledged for bringing up ideas regardless of the final verdict.

More than seven decades later, a fear to express oneself is no longer a cultural dictate. Also, in many organizations, the actual meaning of brainstorming is something like ‘everyone says something without any method and at the end, it is not very clear what to do next’, somewhat of a ‘let’s just talk it/do it’ approach. It is far from the original brainstorming techni que which is very much organized and includes only a phase of ‘free’ conversation.

Move to a workshop set of mind

A few months ago I stumbled upon The Workshopper Playbook by AJ&Smart . I realized that it put in a very good way the notion I had developed previously in vague terms, that if you just put people in a room and ask them to work or think together, nothing comes out of it. Brainstorming does not work, as well as any other ‘free spirit’ approach. Since then, I approach each meeting I organize that includes four or more participants with a workshop mindset. I don’t necessarily follow the method in the playbook, but I make sure I have a clear understanding of the goals and structure of the meeting. The following sections roughly describe my thought process and toolset for optimizing meetings with a workshop state of mind.

Decide on goals and expectations

Actions without pre-thought clear goals are deemed to entirely fail or entirely succeed, and both results are not welcome. If you don’t have any goals you can't succeed. If your goal is to ‘talk and see what’s next’ you have 100% to succeed in talking and seeing what’s next.

Ask yourself what this meeting should result in? Do you want to inform others about upcoming changes and answer their questions? Get feedback on your plans or designs? Decide who is the owner of a specific task? Collectively decide between alternatives? Approve your plans with your managers? Lay down the space of alternatives and analyze them? Each of these can be a goal, and you can also combine several. First thing, be clear with yourself.

Once you know your goals, it is easier to understand your expectations from others. Ask yourself what is it that you need from others in order to achieve this goal. Is it feedback? Approval? Contribution of a professional point of view? A joint decision?

Communicate goals and expectations as early as you can

Allowing others to understand the goals of the meeting and what is expected of them is essential to make any meeting, and any process, effective. When you communicate your goals and expectations in advance, people can prepare in advance. Such preparation might take the form of just thinking about it in advance, or of a well-formed assignment to do before the meeting. You can ask people to read materials beforehand, or even give participants ‘homework’ assignments , especially in case of complex topics that require the input of many people.

Not all meetings require communication in advance. Some meetings are very short or scheduled at short notice, and it’s not worth it to communicate in advance. Also, some meetings might be around sensitive matters and pre-communication could be interpreted in the wrong way, intensifying reactions instead of cooling down the group. In such cases, make sure you communicate goals and expectations early in the meeting.

Next: Story, Context, Scope, Wrapping up

In the next part of this post I will talk about storytelling, bringing people into context, scoping the meeting and wrapping it up. Until then, sign up for updates to get a notification when the next part is live.

Product benchmarks

yonatan.shaham@duda.co (Yonatan Shaham) — Tue, 03 Nov 2020 13:52:20 GMT

One of the challenges product managers are facing is benchmarking KPIs and metrics. When you are about to release a new feature or product, what should you expect? What would be considered a success? Would 5% adoption be a great success or a complete failure?

I think the reason product managers are having a hard time here is due to the fact the product metrics are deeply related to business data and results. Would you be willing to tell outsiders the current values of your product metrics and KPIs? Probably not, they’re too sensitive.

Designers and developers enjoy the ability to share data and specifics regarding many challenges and issues they meet (not all of them). For product managers, it’s harder, as well as for other business-oriented positions like marketing or sales.

(On a different topic, I think this is also why many product managers professional forums and conferences are lacking. No one can really ask about their issues since they don’t want to reveal sensitive information. So all you get is a series of highly generalized vague questions and replies, as well as presentations you can’t learn a lot from)

One solution to this problem is looking into product reports that include benchmarks. Even though some of them may be too general for you, it is usually a good place to start. In this post I’ve collected some good reports I found interesting. I linked to each report and summarized the highlights.

Pendo interactive product benchmark report

Get the report

This report compares 1000 leading products, and reports benchmarks for low (25th percentile), average (50th), good (75th), and best in class (90th) performance. You can see the overall results or break down by company size/stage which is given as start-up, scale-up, enterprise.

The report covers some key metrics:

Stickiness: measured as the ratios of Daily Active Users/Monthly Active Users, and Weekly Active Users/Monthly Active Users
Feature adoption: what percentage of features creates 80% of click volume
Monthly retention
NPS score

Mixpanel Product Benchmarks Report 2019

Get the report

The report surveys 638 products used by 1.2 billion users. The report includes several breakdowns: by industry (finance, media, e-commerce, saas) and reports benchmarks for median (50th percentile) and best-in-class (90th percentile). Most benchmarks are also broken down by platform (web, mobile, mobile-web).

The report covers the following metrics:

Reach: User growth MoM
Activation by industry and type of product
Growth in weekly active users
User engagement: key events/MAU
Weekly activity trends
Retention: 7-day retention, 30-day retention

Pendo 2019 Feature Adoption Report

Get the report

This is a short report with a striking bottom line: Software companies invested up to $29.5 billion in features rarely or never used.

The report looks into the adoption rate of features within a product and finds out that 80% of features in the average software product are rarely or never used.

2020 SaaS Product Benchmarks by Openview

Get the report

This report is more focused on high-level SaaS metrics. Openview is promoting product-led growth, and their findings are mostly broken down by overall product growth rate (low vs high). Benchmarks are reported in quartiles (25th percentile, 50th percentile/median, 75th percentile).

Conversion from web visit to free account signup
Conversion from free account to paid account
Conversion from free account to paid account freemium or free trial
Average percent of leads by acquisition channel
Conversion from free account to paid account by channel
Retention rate after one month by go-to-market approach (freemium vs free trial)
Activation rate by go-to-market approach (freemium vs free trial)
Natural rate of growth by go-to-market approach (freemium vs free trial)

How do I write PRDs and user stories today, and how did I get there?

yonatan.shaham@duda.co (Yonatan Shaham) — Tue, 20 Oct 2020 14:06:16 GMT

The beginning

I got into product management unintentionally and unofficially. As a co-founding CTO of a software startup, I practiced product management with know that it is product management: I decided what our app would look like, how it would behave, and supplied developers and designers with instructions on what to build next. At the time, while working with experienced mentors in a startup accelerator we were part of, I came to learn that all these practices are commonly known as Product Management.

When I started to look for my first ‘official’ PM position I knew I needed to catch up with proper terminology and improve my practices, and I did so. However, I did not strictly follow any format when communicating product requirements to developers, designers, and QA.

This worked ok for more than a year. Often, during retrospectives, developers and QA noted that not all the tasks were clear enough and that they had to go back to me for clarifications. As a squad, we tried to reduce the frequency of such miscommunications in different ways. We succeeded to some degree, but once in a while, someone was complaining about not-clear-enough tasks. It looked like such miscommunications just come with the territory, and there is not much more that we could do.

A new dev-lead

In March 2020, a new dev-lead, Shay, joined the squad and the company. Coming from a large corporate with experience as a Scrum Master, he gently insisted that by the time Jira tickets get to developers and QA, tickets should follow a strict format with two parts. The first part should be in an ‘As X I would like to Y’ format. That is the User Story, and its role is to give context to the people delivering the work. For example:

‘As a new user, I would like to sign up to the app using email and password or my Google account.’

This User Story format is not limited to UI interactions. It also applies to many other types of user's interaction with the product:

Working with APIs: ‘As a user with API access, I would like to create a new order via REST API by providing the following details: name, due date, and a list of items. I would like to get back an Order-ID for future tracking.’
Using internal products: ‘As a support agent, I would like to know the last 100 actions each user performed in the system.’
Developer from within the company: ‘As a developer, I would like to use the pricing service to trigger a new purchase for a user, suppling the user ID and the requested product.’

The second part is the Definition of Done (DoD), and follows the pattern: ‘This is done when…’ This part should include a list of statements, each of them is very clear and can be easily tested, so developers and the QA can apply them directly as acceptance tests. Following the mentioned examples, a DoD for the first user story may be:

There are input fields for email and password, and ‘Sign up’ and ‘Sign up with Google’ buttons, following the attached design.
When a user supplies an email and password and clicks ‘Sign up’ a new user is created with the supplied password.
When a user clicks ‘Sign up with Google’ the Google sign-up sequence is initiated.’

Note that this DoD does not include all the relevant behavior. For example, it does not state anything about the user creation flow or the sign-up with Google flow. There are a few different reasons for that. First, these flows may be already active in the system, so developers just need to make sure the flow is initiated correctly. It also may be that there is another ticket to developing these flows. As a product manager, I always try to breakdown deliverables as much as possible into independent parts. I will elaborate on this point later on.

Pressure builds quickly

So I had to work with a new dev-lead in a new method. To add to that, two weeks after we started working together the whole country went into severe lockdown due to COVID-19 breakout. We had to manage this ticket-formatting change while everyone are getting used to working from home, instead of sitting at one desk. If that wasn’t enough, two days after the lockdown started, one of the company’s largest clients communicated that what was previously only a general timeline for delivery is now a hard deadline and that if we don’t deliver the feature within a month, that client won’t purchase any new services from the company. So this transition did put a lot on the line.

It worked. It did require me as a product manager to be very specific and to commit to the requirements I write. It required developers and QA to verify they understand requirements before the sprint starts. And if we as a squad discovered that something is not clear, or does not fit with the design, or any other issues, we had to go back to the drawing board and quickly decide what to do, so we can start the sprint one time. But once we were done with the planning, we all knew that there was a very high chance that the scope of the sprint will be done on time.

Following up with the success

We stuck to this method, and I implemented it in the second squad I was responsible for. And just a few weeks later, this method allowed us to plan and execute an integration of two complex features into one to deliver much new value to our users.

The essential implication of this ticket writing method on me as a product manager is that I must making have requirements at this format by the time the squad needs to execute. This means that I should communicate my initial thoughts on new features much more early in the process. Back when I allowed requirements to be vague, I tended to communicate the overall goals, intentions, and design decisions quite late in the process. If you are allowed to change requirements later, nothing pushes you to get the team involved beforehand.

Today, when I have a vision of upcoming features, I start a series of ‘kickoff’ meetings with the squad. At these, I share the goals, the high-level requirements, design, and breakdown of deliverables. We get feedback, identify points we missed and raise concerns, and get back to the drawing board with these insights. This way, when we get to the execution phase, we already have very solid requirements in a clear and actionable format.

Not forcing a solution

Lastly, one major benefit of writing requirements in this format is creating a clear separation between the need and the solution. People with entrepreneurial or technical attitudes tend to ‘think fast’ and jump directly to envisioning a solution when thinking of a problem. The downside of this attitude is that they may not completely understand the problem they’re trying to solve. Jumping too early into designing the solution would miss critical understandings and insights about the problem. Writing down requirements in the format of ‘As X I would like to’ followed by a definition of done, does not discuss the solution in any way. It forces you as a product manager to analyze and present the problem in a very clear way, before moving to the phase of designing the solution.

How and why did I work with both Scrum and Kanban at the same time?

yonatan.shaham@duda.co (Yonatan Shaham) — Tue, 20 Oct 2020 12:56:59 GMT

Scrum vs Kanban

When working in squads in agile methodology, many ask themselves with which framework to work: Scrum or Kanban? I worked with both at the same time for more than a year and a half, and both worked very well. Here I will try to explain how did I get to this position and why I think it was successful.

What does ‘Scrum’ and ‘Kanban’ mean anyway? In the most general way, these are two frameworks of Agile software development. Scrum is based on boxed time units called ‘Sprints’, usually two weeks each. Each sprint has a well-defined sequence of ‘Ceremonies’ that aim for selecting what to execute in the sprint and then making sure it is executed as planned. Once the sprint has started its content should not be changed. Kanban is a continuous method in which team members constantly pull tasks from the To-Do list and execute them. The only limitation in Kanban is how many tasks can the team execute in parallel. You can read more at this Atlassian blog post, or just Google both terms.

Spinning a new squad

Soon after I joined the company, Duda, the Product-R&D organization went through a deep organizational change: starting to work in squads. Each squad had a product manager, a technical lead, developers, QA persons, and a designer. Each squad was asked to choose how they want to work and to manage their work autonomously. We could choose Scrum, Kanban, or anything else we wanted.

I was assigned as the product manager of the Platform squad. This squad was responsible for multiple domains: an emerging product, an app store where third-party products were integrated into Duda’s product; the Widget Builder, a small platform for our users to develop their own website widgets and reuse them on multiple sites; the company’s billing systems; and the APIs and webhooks not related specifically to any other squad.

About two months down the road, me and David, the squad’s tech-lead, came to the understanding that the squad cannot be owning the billing systems together with the other domains. We articulated the reasons and approached our managers, and the result was spinning off a new squad owning the billing systems, titled ‘Pricing Squad’. One of the experienced billing developers, Fabio, was promoted to lead the new squad, and I was now a product manager of both squads.

One squad Scrum

There were several reasons to spin off a new squad. One became very apparent soon after: that each squad needed a different framework. The Platform squad continued to work with Scrum, while the Pricing squad turned to Kanban, meaning I practiced both. The reasons for that are rooted in the traits of each of the squad domains. The Platform squad is a product-centric squad, which at that time was very focused on delivering Duda’s new App Store. We had to make tangible progress towards a working product each week. We did not have a lot of distractions, as the other domains we were responsible for were well established and in maintenance mode.

Moreover, as the App Store is an integrative product with third-party teams developing into our infrastructure, we aimed for predictable timelines that can be communicated to our app-partners. The Scrum framework fits these considerations very well. The two-week Sprint cycles allow us to make product progress, to estimate it ahead of time, and to communicate expected progress to partners. Developing a new product also means fewer technical constraints, meaning developers can design the solution of each requirement very close to the execution. With Scrum, it is very much possible that developers are becoming familiar with the details of a requirement just a few days before the in which this task is to be executed. If most tasks would require a few weeks of detailed research, running with Scrum would be quite difficult.

One squad Kanban

The Pricing squad is almost a mirror image. It is a very operational squad. Since the billing systems are key operational systems and are very complex, the squad needs to pay constant attention to bugs, alerts, and escalations from support. Product focused teams can decide not to fix many kinds of bugs or not to address many feature requests - if the squad finds that investing in other areas will better support the company. In product-focused squads, it is very likely that even though a specific user flow crushed the system occasionally or is not clear enough, there are other product improvements and features that are expected to have much greater returns to the company. But this is not the case with billing operations. If a client is over or undercharged, it must be fixed soon, even if the underlying cause will be addressed later on. One of the main difficulties we experienced before spinning off the Pricing squad, was that in each Sprint we had to keep a ‘black box’ placeholder for pricing escalations that will come up during the two weeks of the sprint. More often than not, there was no connection between the efforts we planned to invest in these placeholders and the actual time the squad spent on them.

Also, many times the Pricing squad is required to support initiatives of other business departments outside the product-R&D organization such as A/B test on the pricing plans, marketing promotions with coupons, and more. Lastly, the technical nature of the tasks is much different. As billing systems are very complex, sensitive, and interdependent with external services such as credit-card processors, most tasks require a long research and design phase before execution can actually start. Giving all these traits, Kanban is a natural choice. It allows high flexibility and quick response to incoming issues and business initiatives. It supports execution driven prioritization for long development phases and continues integration, both allowing developers to manage execution following technical considerations. It allows conducting research in parallel to execution, a long time ahead as needed.

My personal split continued for about a year and a half. For me, it was in fact very easy to work in both frameworks in parallel. With time, I also got confident in the fact that each squad chose a framework for the right reasons, and not following a convention or some other form of groupthink.

Yonatan Shaham's blog

How I Accelerated My Game Development by 30x Using AI

Online payments for product managers

Designing payments and billing experiences

1. Keep it simple and standard

2. Break down delivery

3. Think about permissions

4. Be consistent and clear

Statement Descriptors

5. Collaborate with business units from day one

Online payments terminology

Billing terminology

My problem with RimWorld and the game I’m trying to make

RimWorld problem #1: too much content

RimWorld problem #2: controls and situational awareness are difficult and consume the player’s energy

RimWorld problem #3: information is too explicit

What I do like? the “Tycoon” effect

How does all of this relate to the games I’m trying to create?

Designing basic UX for the maritime trader game

Product, design, or coding: Always start with the big picture

Speed up delivery time: reuse what you can

Closing the loop and thinking about UX

Coming up with a win condition

Product management aspects

Product management principles in practice: indie game development

Push for early validation of assumptions

Deliver a working software

Get feedback early

Why do things this way? Can’t I just work another 60 minutes?

Taxi + Trader Roguelike = New Game

How should I combine the two games?

Core game mechanics: nested game loops

Product manager resume: top 3 mistakes

Key takeaways for writing a product manager resume

Spell out activities you did as a product manager

Clarify companies, products, and teams you engaged with

List your achievements

A difference of night and day

Mouse movements, testing

UX improvements, user testing

Graphic UI

We have a game loop

Starting trader rougelike

Starting to post daily about game making

Product manager: be a professional, not an artist.

Key takeaways

Moving the needle as a wizard

Who is a professional?

What is a profession?

Product managers as professionals

Validating a game idea using a text-based adventure

Being stuck

What does validation mean?

Implementation

Results

Conclusion

Part two: Product presentation and meeting tips (Brainstorming does not work)

Present in a way that tells a story and gives required background

Give background and context ﻿

Follow a logical order ﻿

Human interaction in groups is important and can be done only when everyone is present, give it time

Wrap up clearly and set follow up

You can cancel meetings

Product presentation and meeting tips (Brainstorming does not work)

Preamble: Brainstorming does not work

Move to a workshop set of mind

Decide on goals and expectations

Communicate goals and expectations as early as you can

Next: Story, Context, Scope, Wrapping up

Product benchmarks

Pendo interactive product benchmark report

Mixpanel Product Benchmarks Report 2019

Pendo 2019 Feature Adoption Report

2020 SaaS Product Benchmarks by Openview

How do I write PRDs and user stories today, and how did I get there?

The beginning

A new dev-lead

Pressure builds quickly

Following up with the success

Not forcing a solution

Give background and context

Follow a logical order