Posted on

Discovery & Delivery in Product Management at Typeform

In itnig’s Podcast #26 Bernat Farrero, CEO at itnig and César Migueláñez, Product Director at Factorial, talk with Pol Narbona, Product Owner at Typeform about Product Management.

Pol shares his story with us: How he arrived at Typeform, how he started out as a Product Owner and gives us a little overview on how he works with two road maps — Discovery & Delivery — in Product Management. For the whole talk you can view this video on the Dual Track Agile methodology:

At itnig every Friday we sit down to talk with interesting people whom we meet throughout the week and we make a podcast (in Spanish) out of our conversations. You can listen to it on iTunes, subscribe to our channel on Youtube or enjoy it through iVoox.

https://upscri.be/5c88ff/

First of all, we ask him to situate us and give us a bit of context before we enter in detail into his career path.

What is Typeform?

Typeform is a software for online data collection: forms, surveys, register forms — converting a bureaucratic thing into a conversation. But this is probably just the boring explanation of the produc t— we are really strong in design and user interaction.

How did you arrive at Typeform?

I am from Barcelona and started to study here but then I had the chance to go to the US with a sport’s internship. In the 3rd year at uni I was doing some market research and needed to create a survey, I used Typeform and when I shared the survey the respondents were really surprised. I was studying Business & Tech and when I was finishing uni I started to look for jobs all over Europe. Actually I think Typeform was the only company in Barcelona I applied for. As they did not have any open positions in the Product team I started as Data Analyst, as part of the Customer Success team. Here I came to understand user behavior and I started seeing how the product team works. After a while and a restructuring of the teams, I applied internally for product owner position and here I am now.

I finished my university studies and started working at Typeform a year and a half ago. At that time I was employee #90 if you will and now, 1.5 years later we are about 180 people in the team. I think this gives a good impression of our rapid growth.


How do you work at Typeform in Product Management?

At Typeform we separate ourselves into different product teams, distributed along the User Journey:

  • Discover (top of the funnel, acquisition, public sites)
  • Subscribe (user subscription, demo environment to try product)
  • Conclude (results based work, e.g.integration with partners)

In the Conclude team for example we work in different colonies with Designers, UX, Developers, QA and Product Owners. The colonies give us the info that people working in this colony are focussed on this part of the user journey.

These colonies are not hermetic, we switch between teams, actually it is pretty common for developers to be working on different parts of the funnel from time to time. This allows us to divide the product up in different parts and assign an objetive and metric to each of them.

However, we are changing this again as we discovered that there are lot of dependencies. For example: We wanted to create a user journey for a specific persona but if other teams are working on other priorities there are dependencies that arise. Now we are going for a more horizontal approach to have more context at the moment of working together.

And you said you use Dual Track Agile as work methodology?

Yes, we do Discovery & Delivery in parallel. While the team works on delivery of a tested feature, I can dedicate myself to identify new opportunities that come later.

In general, throughout all teams we work in 2 weeks sprints and with Scrum. We have seen that these are compatible with the Discovery & Delivery Agile roadmap.

If you are interested in finding out more about his work methodology at Typeform, we encourage you to listen to and watch his talk at itnig as well.

Listen to our podcast to learn more about Product Management at Typeform and Pol’s experiences with Discovery & Delivery. Learn more in this Podcast in Spanish on our Youtube channel, listen to it on iTunes or enjoy it through iVoox and subscribe to our newsletter to stay always up to date.


Posted on

Learning the Design to Code process

Even if you’e not a designer and never used design software before, you can still release products that do the job and are well designed.

The following steps I’ll guide you through can be divided into three parts:

  • Planning
  • Designing
  • Coding

It’s far from a complete UX process, but it will allow you to take your own design and make it come alive.

1. Plan it

In your initial phase of planning you need to know your goal, and what you want to achieve with your project.

When you know for what purpose you’e building your app or your product for, you need to know who’s using it.

You should think of your audience in three different ways.

>Who: Demographics, age, gender, profession, etc.

>Where: In what setting they will use your product in.

>What: The kind of device they’re using your product on.

Take this information and let it influence your decision as you design.

The next step is to do at basic flowchart, in other words see how the user goes through your product, step by step, instead of just hard-coding it.

When you make a flowchart you avoid making mistakes that forces you to go back and do big changes. An example of a flowchart I’ve used in Quipu is pictured under to give you a rough idea, but if you want to dig into it — here’s a video explaining the process using Sketch.

It’s extremely important to have a thorough plan for whatever product you’re designing. It will save you time and effort for sure.

The last part of the planning, is to define a functional definition of each page in your product. It’s a document that will be your documentation or knowledge base about what each screen does, what it shows, and what routes and actions are possible to take from there.

So if you’re building an app, you should have a page with the following information for each interface:

Name of the view (or the module) –> The purpose of the page –> Full information –> Partial information –> List information –> Routes/actions.

If you did your flowchart correctly, the documentation will be heavily dependent on that Flow Chart.

2. Design it

The most important thing as a fresh designer or working on a project you’ve coded yourself, is to use established patterns.

There’s no reason to reinvent the wheel again.

A place where you can find questions and answers for most issues are ux.stackexchange.com. It’s similar to stackoverflow.com, just for design, and we know how important that is to most designers, so don’t be afraid to seek inspiration and help from more experienced people.

Then start on your wire-framing. Translate your flow and functional definition to a low-fidelity screen that contain everything but the design finish. In other words, focus on getting all the routes, actions, buttons and content right before making it look nice.

One of the most important thing of the design process, is to design it like you would code it. I recommend using Sketch, but use whatever software you’re comfortable with, like Illustrator or Photoshop.

Design as you would code it simply means using non-filled transparent containers to imitate containers and wrappers. Also use naming conventions for layers and groups just as you would use while coding your components.

The last thing I want to mention in terms of design, is to use Atomic Design principles which is a way of designing interfaces that extends to what we’ve been covering in the “Design as you would code it” part above.

It talks about structuring your design, and define it into atoms (colors, fonts, shapes) and form molecules by using them (buttons, inputs, lists etc..), to finally do organisms. An organism then becomes a template For example, A navigation bar that has a menu, a search bar and a logo (few molecules).

Foto: http://bradfrost.com/blog/post/atomic-web-design/

3. Code it

As a designer I will not teach code, most of you probably are more talented coders than I am, so I’ll just mention the software you should use to help you get all the CSS styles you will ever need.

Zeplin.io is a software that takes Sketch Designs, exports CSS styles and gives you all the sizes, margins, paddings, borders you need in order to translate your design to code and not loose the quality and level of detail you worked so hard on.

Zeplin.io is in my opinion the best way to translate design to code.

If you followed the atomic design, and designing as you would code it, then this process is simple, quick and with minimum errors.

I can honestly say that in Quipu where I do the design, this is the most time-saving tool I’ve ever come across. It drastically reduced both cost and time spent on getting the looks of our apps and website translated to all browsers.

Also read:

https://blog.itnig.net/why-ux-ui-designs-should-be-aimed-at-zombies-1968d72b0472

This post was written by media manager at itnig, Sindre Hopland, based on the presentation by lead designer at Quipu, Kamil Jura.

Posted on

What you need to know before building an API for your product

First of all, this is a non-technical approach to API’s, so if you want in-depth tech insights, I recommend you get in touch with Hitch — the API experts.

However, if you’re looking to get insight in why you should use API’s to strengthen and grow your business, and what metrics you should be aware of when taking advantage of an application programming interface (API), you’ve come to the right place.

A whole or core product?

To really understand how your company can utilize API’s we need to understand the concept of the core product and what many call the whole product.

Famous marketer Regis Mckenna that helped launch the first microprocessor for Intel and the first computer for Apple said it like this:

(…) A whole product is a generic product augmented by everything that is needed for the customer to have a compelling reason to buy.

So for example a computer is a core product, and the mouse, the software, the screen and any other necessity being part of the whole product.

It’s very important to understand these definitions, because having insight here will help you know how to approach your customers, potential partners and competitors.

Hacking partnership agreements

As your startup grow, you’ll probably be looking to form partnership agreements with other complementary products and companies.

This can be super valuable, but often takes a lot of time and effort, in other words, it’s often very expensive.

So to hack this time-demanding and expensive process of partnering up with other companies, and API can provide this kind of partnership without all the hassle, often at a fraction of the cost.

Bruno Pedro is the CTO of Barcelona-based API startup Hitch. He explain that many underestimates the cost connected with taking use of an API, especially the cost of support.

The thing with building or using an API is that it doesn’t matter if you consider yourself as a part of a whole or a core product. If you’re able to see through your customers (or potential customers) eyes, you’ll probably discover how your product can transmit value both as an integration into a bigger product, or as an integration to enrich smaller products.

The cost of integration

Integrating your product with other businesses through an API offers many possibilities, but also new costs related to integration.

Development costs start out high, but turns to zero as the product finishes. The maintenance costs remains low but stable with a few peaks around new releases with bugs attached. The big cost related to support which will be higher as your API becomes more popular.

Development costs: very high at first, but becomes zero when the API is launched.

Maintenance costs: high after the launch because of bugs, and for every iteration you do you’ll have peaks with your maintenance costs, as well as routinely maintaining the API itself.

Support costs: This will depend on how well your API is performing, but the more users you have, the bigger the support cost will be, so this is the really expensive one.

And remember, these costs need comes with each separate integration.

So, is your API worth the effort?

In other words, we need to understand the life time value (LTV) of our integration.

First you need to measure where your customers come from, then you need to identify the new customers that are using one of your integrations within a specific timeframe and estimate the lifetime value (LTV) of those customers.

Then, when you know the LTV of each particular integration, you can easily know which is giving you growth, and which that are only causing costs to rise.

The last thing you need to figure out to see if your integration is worth doing is the payback period (PBP), i.e if your integration or your API is earning you more money than what you’re spending on it.

To find this number you have to take all of your costs (as mentioned above) and divide it by your monthly recurring revenue (MRR), and again, you have to do this for each integration.

https://upscri.be/285782-2

Getting to the good stuff — growth!

Your product can be the core product which is the big one in the middle, or part of the whole product which is one of the smaller ones on the side. No matter where you are in the ecosystem, you’ll have costs related to the integration.

To be clear, with growth we don’t mean a profitable company, but a business that is multiplying their growth month over month, or year over year. It can even be unprofitable.

So what is growth for an integration?

  • In most companies it’s considered growth if the lifetime value of the integration is three times higher than the cost of integration. If not you’re loosing money. Some experts say that 4 times higher LTV than costs is the number to aim at.
  • And not enough with with a high LTV, it also considered necessary to have a payback period of less than 12 months. If not, you’re also loosing money.

So remember, if you think about how your company is used in a broader context, and not only how its used as intended, there may be many possibilities with using API’s.

This post was written by media manager itnig, Sindre Hopland based on the presentation of Hitch CTO Bruno Pedro.

Posted on

Demystifying the product manager, and how to become one

As product focus is more important than ever in building startups in a very competitive market, the product manager role is increasingly getting more common and is highly valued.

But to many it’s a job description that’s a bit vague, and often means different things from company to company.

We invited three product people from the startup ecosystem in Barcelona to discuss the topic: Former PM at Google and currently product consultant Itamar Gilad, CEO and co-founder of Factorial Jordi Romero, and CEO and co-founder of Quipu Roger Dobaño.

Long time product expert Gilad says it’s hard to explain the PM role in one sentence:

The position has changed so much over time, and it’s still changing. I like to define the PM as the person who’s the expert on the users, the customers, the market and the competition, and manages to deliver this context to the product team in a good way — it’s a super man basically!

From product to customer first

From the left: Sindre Hopland, media manager at itnig, Jordi Romero, CEO and co- founder of Factorial.

The last 10–20 years, tech companies have shifted their focus from trusting their engineers more than market, to lifting the customer and the users as the number one priority in making the product, says Gilad that for the last six years has managed products such as Gmail and Youtube:

The first time I heard the term product manager was back in the 90’s, and back then it was very new. The thought was that engineers always knew best, but that has changed a lot.

Also Romero, CEO of Factorial, recognizes the attitude from earlier times when he worked in other SaaS companies in the US and in Barcelona:

I remember we first defined ourselves as a product-first company, then a sales-driven startup and later a customer focused company. It think these terms are hard for startups that alter and change the way they do business often.

Dobaño is both CEO and head of product at accounting SaaS Quipu, he defined the product role like this:

You’re the CEO of the product, but it’s not just about making a great product, it’s about continuously solving problems for the customers and making an impact in your customers life.

All the responsibility, but no authority

The product manager is found somewhere between tech, business and the UX/UI team of the startup. © 2011 Martin Eriksson.

Even though the PM has the word manager in the title, all three guests agrees that the only thing the PM actually manage is the product itself.

Romero points to several challenges connected with this kind of responsibility:

An issue I’ve seen in many product teams, is that the PM is managing the team itself, and not only the product and process. I think this is a real problem that is hindering the communication in the organization.

Itamar explains that the PM is there to fill all the holes of work that aren’t being worked on, which means that the person needs to be diverse:

The PM is working closely with both customer service, the business side, designers and engineering, it’s more about creating a pattern for collaborations and a good flow of progress. It’s needless to say that soft skills are in high demand.

He continues to say that a startup needs a designated PM when the startup is at a scale where the business people and the engineering team start arguing what to build next, and you don’t have time as a CEO to deal with all the discussions.

How to become one

From the left: Itamar Gilad and Roger Dobaño.

Romero says he believes a lot in promoting PM’s within the company that share the original values and vision of the founders.

Itamar explains that it’s not necessary to know how to code, but many big companies require it:

In companies like Microsoft, Apple and Google they alway prefer someone with a coding background. However, the personal also needs to be interested in the business side of the startup and have strong soft skills for team management.

Dobaño thinks many companies are setting too high requirements for their PM’s:

What you’re describing here is a unicorn. I do agree that PM’s should have a computer science background, but my job is to empower one person within each product team, and I’ll then make sure the communication flow is good between the company.

Romero repeats how vital soft skills are to this profession:

To have all the technical skills is one thing, but to be able to both do a sales pitch and to convince the developer team that what they’re building is the right thing to focus on, that’s tricky.

This post was written by Sindre Hopland, media manager at itnig and produced together with Masumi Mutsuda.

https://upscri.be/285782-2

Posted on

How important is networking for your startup? (Isn’t hard work enough?)

Some of our hard-working people at itnig.

If you’re running a startup, or working in one, you probably know how much work it takes to build a brand new product from scratch. It’s not unlikely that you’re reading this post by your desk at 10pm, just because you needed a break from your sweaty keyboard.

But no matter how much and how hard you work, it’s not enough. At least that’s what some experts claim.

Most humans are social creatures, and even though the tech world is built by developers (not famous for being super keen on networking), the startup industry arranges more networking events than most other industries.

In Barcelona you can go to several events every night if you have time.

Is hard work enough?

As I’ve worked as a journalist, meeting founders and entrepreneurs every week the last year, I’ve been asking several of them why I haven’t seen them at tech events before?

The answer is usually:

“We’re busy working, I don’t have time to attend events and drink beers several times every week.”

It’s a valid point. Nine out of ten startups fail, so working day and night makes perfect sense.

I went to cover a startup competition for a major European tech blog earlier this year. After tough competition between some of Spain’s best performing startups, one of them were crowned the winner. Me and my college were surprised that we hadn’t heard of the company before, and asked them how they went beneath our radar. The founders told us:

“We usually never go to events. We actually signed up for this competition almost by accident.”

This made me wonder how many other great startups go under the radar, missing out on important exposure because they’re too busy working (too hard?).

Another example is the founder of Tradesy’s, Tracy DiNunzio, who says she thinks too many founders are wasting time going to tech events:

When I was bootstrapping through Tradesy’s first two years, I never attended events. Instead, I stayed focused (obsessed, really) on improving our product and technology. I was glued to the computer for 17 hours a day.

Building a network

It’s clear that networking is important, but it’s probably also true that many entrepreneurs would benefit more from working, than from sipping beer at tech events every other night.

To some people networking is the most natural thing to do, the ones that have the gift of speaking to anyone, anywhere about anything (or nothing). To them it’s like breathing.

For others it’s more about building a network, doing a job, rather than talking to a massive amount of people. And to some people, a small group, it’s torture.

But no matter what group you belong to, as long as your startup is being built, you’re the product. Before you have users, customers, a physical product, or any metrics at all, you and your team are the only thing representing your startup.

Connections are key, and good advice are extremely valuable, especially from people with experience from your own industry. But tech connections are not necessarily found through going to events.

It’s about being present, and especially talking to the right people. It does not have to be at tech events, but any place you can meet people caring about the product your startup is building.

Connecting to people via mail (or social media etc.) can be just as good as going to an event. Mark Suster made a good Snapstorm on how to send email intros, because there are mistakes to be made.

To sum it up:

Growing a solid network of people in your startup ecosystem can never go wrong, not to think about the vital support you can provide to other entrepreneurs building their respective upstarts.

But hard work is still as crucial as it always has been. Just because there is an event every night with great headliners and interesting topics, does not mean you have to attend.

Tech events are often a blast, and networking is good, but not for the sake of networking itself. Going to events will rarely create more value than a well-functioning team can accomplish in the same amount of time.

However building a network and providing value for your ecosystem is guaranteed to benefit both you and your startup. Just don’t do it on the expense of your startup.

…….

This post is written by Sindre Hopland, Media Manager at itnig.