“When is that going to ship?”

If you’ve been a PM for more than 5 minutes, you’ve heard this question, which is much easier to ask than answer.

Making matters worse, the question is central to what you do as a Product Manager, while largely being beyond your control; you don’t write the code, nor fix the bugs. The best you can do is help with scope, testing, and relaying information when everyone needs it.

Yet, there’s more you can do to help ship features on time than you may think, which is what we’re covering today.

How to Help Your Engineers make Better Feature Delivery Estimates

When you make the lives of the engineers and designers you work with easier, everything gets better; they enjoy working with you more, it becomes easier to make requests of them, and delivery often happens on a more consistent basis.

And to get all those benefits, it starts with YOU.

Before you start pointing fingers at engineers who “can’t hit a deadline” or “stink at estimating”, try some of these approaches to do your part.

You may be surprised how much this boosts your product team’s morale, and how much more accurate the estimate you receive from engineering become.

1) Break your tasks and projects into smaller pieces.

One of the biggest mistakes I see inexperienced product managers make is to plan for grandiose, multi-month (or multi-quarter!) projects. They have a grand vision of solving every little problem possible and completely re-imaging a part of the product that they own.

While this may feel great for your ego, and even be a bit inspiring to others, it’s a recipe for disaster in practice.

Big Projects = Big Misses.

The fact is, it’s very hard to estimate big projects; the larger the span or reach of the project, the more things that can go wrong unexpectedly, and the more dependencies start to stack up. No matter how experienced an engineer is, it’s hard to accurately estimate massive projects. No one can foresee everything that will come up at that point.

That’s why breaking your projects into smaller pieces is so valuable.

Think about it: If I give you a roughly day long task, and you’re off by 50%, that’s only half a day.

That isn’t that big a deal, and is unlikely to sink your plans and other commitments.

Yet, if I estimate a project will take a month and I’m off by 50%, well, now we have to spend an extra 2 weeks on it. That does start to impact the rest of your roadmap and best laid plans.

Best of all, by breaking your projects up into smaller pieces it forces you to:

• Prioritize the most important work: You can’t have everything, but you can make sure you get the most important things done.
• Have real discussions about tradeoffs: Smaller projects means fewer points in your project management tool, so you open up discussions about real tradeoffs instead of simply piling on more to do.
• Think about big projects in phases: Do you really need to wait to have *everything* you can dream of, or can you launch in phases, possibly even pausing work between phases to give attention to other needy parts of your product?

All of these are good discussions and thought experiments to have as a product leader. By practicing them proactively, you’ll improve your relationship with the engineers you work with, because now your requests won’t feel like you’re always asking for mountains to be moved.

2) Give your Engineers a heads up for unknowns and complex projects.

Quick: You have 5 minutes to think through all the consequences of a massive project that will probably take 3 or more months. Make accurate estimates, and start making project tickets now, because this conference room is reserved for someone else in 22 minutes.

Sounds unreasonable, right?

Yet, that’s exactly what a lot of PMs do. They come to sprint planning meetings with enormous projects that are only defined at a high level.

No wonder engineers miss deadlines. They’re given an impossible task.

Start your discussion well before sprint planning.

You know who the tech lead, scrum master, or other lead planner is on your product team. That means you should start the discussion with them early when it comes to bigger projects or greater uncertainty.

I’ve always found that if I come to the right engineer with a sticky problem or complex question, they’re excited to dig in and see what they can figure out. They’ll then come back with:

• What the hard parts about that task/project are
• What they think is reasonably possible
• Approaches they suggest are hard vs. easy
• Rough time estimates for various part of the work
• Suggestions for further research and discussion

The key to all of this though is timing.

While coming the day before sprint planning is better than not coming at all, what you really want to do is give them a week or two warning.

That gives them more flexibility on when they look into it, and it gives them time to really marinate on their answer.

I often find the best engineers will do this over multiple days, talk to some friends and coworkers, test a few things, read some docs, and ultimately come back with a super informed answer IF I give them enough forewarning so that they have time to do it (while completing the rest of their work commitments, of course).

As Ben Franklin said, “an ounce of prevention is worth a pound of cure.” You can save your team a lot of headaches from poor estimations by given your engineers a heads up so they can do more research for your larger and more complex asks.

3) Be flexible on scope, but firm on outcomes.

To be successful long term, product managers have to be pragmatic. If you try to control every detail, and you’re rigid in your approach, don’t expect to deliver a lot. You’ll also frustrate your engineers and designer to no end.

One of the best ways to lead your product team to successful outcomes that are delivered reasonably close to on schedule is to be flexible on how you solve problems, while holding firm to solving the most important problems for your customers.

The truth is, customers do not care how hard or easy what you delivered was. All they care about is if you solved their problem.

Know what to fight for.

Surprises happen. Timelines slip. Fires come up that have to be dealt with. You can’t let projects drag on month over month or quarter over quarter.

When issues inevitably come up, you have to find the right things to compromise on. That means knowing what to fight for and what you can be flexible on. Be prepared to answer questions like:

• What outcomes are must-have for your customers? There are times where not having something defeats the entire purpose of the feature. You can’t cut that. Fight to keep it in your plans, and explain why so everyone understands your resistance.
• What is the 80/20 (Pareto principle) of this feature? Yes, we’d all LOVE to build everything we can dream of, but when racing to product/market fit, or simply overrun by roadmap demands, you have to focus on the highest impact aspects. What will add the most value for the least effort or number of features?
• What can wait? It helps if you already have a few things in your back pocket that you’re okay de-scoping from a project. Maybe it can fit in a “Phase 2” of a project, or you can squeeze it in as part of a quick iteration post launch.

The beauty of a high performing product team is that you don’t have to have all the answers. Engaged engineers and designers want to help you get the best outcomes for customers. When you get stuck, they can help you come up with the best solutions given your constraints on time, resources, and tech challenges.

Through all those discussions, it’s your job to keep things anchored in the reality of what needs done. That means remembering the metrics and outcomes you’re driving towards so you cut and keep the right things.

4) Write clear, concise, effective product specs 

You know what often precedes a poorly planned sprint? A poorly written product spec.

You get out what you put in, and too many PMs shortchange their product specs. They either rush them, so they only have half of the information needed, or they bloat them with so much fluff and fill that no one wants to read them.

Both of those extremes are recipes for disaster.

Great product specs are a precursor to accurate estimates.

When you give your engineers and designers a product spec that covers everything they need to know, and makes clear the priorities, it’s much easier for your product team to come up with the best possible solution within the constraints you have.

Unfortunately, a lot of product specs shortchange this kind of information, sometimes even spending a lot of time dictating the solution to their engineers and designers instead.

Don’t do that.

Instead, make sure your product spec includes key information including:

• Why are we working on this? This sets the narrative and should share the hard data that justifies making this the priority to work on.
• What problems do we need to solve? These should clearly lay out what this project should address. They should be ranked so you’re all on the same page, and know what can and can’t be cut.
• What are future considerations for this? You can’t always build everything you want, but by having a section for this, you help your team make better decisions anticipating these things coming. This will save you time & frustration later, and gives you a clear place to move things that get descoped.
• What is our KPI/OKR/Metric for this? This ties back to your why. It helps measure success or failure and keeps everyone focused on what you’re trying to do. Remember: shipping is not success as a PM. Driving successful business outcomes is.

Creating a succinct, clear, and effective product spec is a big challenge and an important skill for every PM to master. If you think yours could use a tune up, check out How to write a Product Thesis, which I learned from Silicon Valley investor and product leader, Josh Elman.

Product specs are a high leverage activity for product managers; when you do the work to have the right information and then organize it well into a quality spec, you may be surprised how much easier it is to work with your engineers and designer. Your improvement in this area will then set up your team to give you better estimates.

5) Talk about estimates and scope before you plan a sprint

Yeah, I know. Who wants another meeting?!? In this case you do.

One of the most powerful meetings you can have comes from the meeting before the sprint planning meeting.

In this meeting, you go over your product spec, talk about the project goals, and then bounce ideas around until you settle on what’s possible given the needs, constraints, and possibilities everyone comes up with.

This is literally my favorite part of being a product manager, yet it seems many people don’t know about it nor do it.

Thankfully, Steve Jobs led the way on these.

Steve Jobs and the Cauldron

No, this isn’t some kitschy Product Manager’s children’s book. It’s a real thing that Steve Jobs did at Apple regularly. As shared by Glenn Reid, who worked with Jobs at both NeXT and Apple, cauldrons are a magical small group meeting where great products are born:

"When I worked with Steve on product design, there was kind of an approach we took, unconsciously, which I characterize in my mind as a "cauldron." 

There might be 3 or 4 or even 10 of us in the room, looking at, say, an iteration of iPhoto. Ideas would come forth, suggestions, observations, whatever. We would "throw them into the cauldron", and stir it, and soon nobody remembered exactly whose ideas were which. 

This let us make a great soup, a great potion, without worrying about who had what idea. This was critically important, in retrospect, to decouple the CEO from the ideas. If an idea was good, we'd all eventually agree on it, and if it was bad, it just kind of sank to the bottom of the pot. We didn't really remember whose ideas were which -- it just didn't matter."

Most importantly, this small group discussion focused on creating the best possible outcomes for customers:

"...it wasn't magic, it was hard work, thoughtful design, and constant iteration. Doing the best we knew how with what was available, shaping each release into a credible, solid, useful, product, as simple and direct as we could make it. And we shipped those products, most importantly."

You have great engineering and design resources on your team. Why would you not want to involve them in coming up with the best possible features?!?

When you know you have constraints to work within, and want to create the best product, then you should be like Jobs and leave your ego at the door. It should not matter if YOU came up with the idea; it should matter only that your product team delivered the best possible product to your customers.

And that comes by meeting to discuss ideas in a free form, creative way, like the cauldrons Steve Jobs used to have.

Then, once you have all the best ideas, and have accounted for the goals, constraints, deadlines, and demands of the project, now, you can move to the nitty gritty details of sprint plans and detailed estimates.

By having this discussion before any estimating, you give you and your team room to consider a variety of ideas. The end result will turn out to be better than anything you or any peer could have come up with alone.

Better solutions, better outcomes, all with better estimates. What more could you ask for?

You have more control over engineering estimates than you think.

You’ll notice none of these suggestions involve playing project manager. None of them involve standing over your engineers barking orders, nor criticizing and complaining, either.

Instead, it gives you ownership over a process that addresses the issues that often exist upstream of engineering estimate issues.

When these areas are done well, you’ll often find a lot of your other problems go away; not only will your engineers improve their estimation ability, but your working relationships will improve, morale goes up, and you will likely start shipping more product with better outcomes.

Do you need help with your product team?

I help VPs of Product, Heads of Product, and 1st PMs at early stage startups that are struggling with critical issues like churn, growth, product velocity, product team dynamics, and stakeholder relationships.

If you’re a founder who would like a coach to help your VP / 1st PM, or you’re a product leader who wants help, learn more about the work I do & happy clients here, or sign up for a free call to discuss your challenges here.

Image credits: Icons by noomtah at Flaticon

If you launch a feature and you don’t tell anyone, did you really launch it?

Okay, maybe the “tree falls in a forest” analogy isn’t perfect, but you probably get the point: you need to tell your customers when you make improvements.

But how do you do it in a way that customers will care?

I’ve seen dozens of ways for people to do product updates over the years, including these common ones:

• Popping up in app to tell them (think Intercom-style, or a product tour)
• Posting on your company blog
• Emailing to everyone who has an account
• Passing it to sales or account management to tell customers
• Updating a change log that lists all updates over time
• Praying they stumble upon the changes

Of all of those, my favorite is the semi-regular email to customers.

I like it for a few reasons:

1. Flexible medium: I can write and include images and gifs to clearly show what’s new.
2. Non-interruptive:  Unlike pop ups in app, they can read this when they have time, instead of dismissing it when they’re in the middle of something in your product.
3. Reminder we exist: People get busy. You are not the center of their universe. An email about product improvements can get people back into your product they haven’t logged into in a while because they see you in their inbox.

For the past 10+ years, I’ve been sending product updates at the SaaS companies I’ve worked at and founded. Because of the structure I follow, I’ve seen it help build stronger relationships with customers, reduce churn, and help everyone feel more product momentum.

Today, I’ll show you my process so you can experience those benefits with your customers, too.

How to Write Product Updates that Delight Customers & Reduce Churn

First and foremost, credit where credit is due. There was an AWESOME Tweetstorm from Steven Sinofsky on this subject. It’s since been taken down, but you can read it in full here.

WordPress also saved the text of some of the tweets, which I’ll share some highlights throughout this post.

Okay, so now that you read his 20 tweets, you understand why this is important, and the pitfalls to avoid. Now, let’s talk about how to actually write one.

A few assumptions:

• You talk to customers: If you talk to customers, all of this is easy to do. If you don’t, not only is this very hard to do, but you are a disgrace to product managers everywhere. Worst of all, your designers and engineers are rolling their eyes at you. Want to fix that? Jump here on my blog to learn how to talk to customers.
• You’re data informed: Quantitative numbers are not everything, but they’re very important. They help you understand how many people are affected by a problem, the total addressable audience for a feature, and measure the impact of a change. Having these numbers is key for both internal buy in and explaining things to your customers.
• You have buy-in: The bigger your company, the more stakeholders you need to manage. It’s good to get things done, and it’s also good to keep people in the loop who also interact with customers or care about this. Use your best judgment on who may want to see what you’re doing. If you get resistance, try to get support for an experiment of sending them.

If you’ve done those 3 things, you’re ready to apply these tactics to make an awesome product / feature update.

1) Start with a “Thank You”

Every product update I take the time to write out a list of thank yous to customers that took time to report bugs, share feedback, answer questions, or do customer development interviews.

This costs you *nothing*, but can mean a lot.

First, you’re letting people know you were really listening. It reminds them that their input matters and the time they took out of their day to email you, hop on a call, or beta test a feature was worth it.

It also creates a reinforcing loop:

• You thank someone for feedback.
• Others see that you thanked people for feedback and it gets them thinking about giving feedback.
• Coworkers see their colleague’s name and talk about it, think about using the product more, and consider giving feedback as well.
• Next month, the list grows, and you have more people to thank.

Immediately after I give thank you shout outs, I also then remind people just how easy it is to give us feedback, so I teach more customers what to do:

Remember: You want a product people LOVE or HATE.

Silence is your enemy.

Make more people care by letting them know you’re listening. The feedback and problems they share help you build a better product, and improve adoption throughout a company or network.

2) Tell your story

Every product has a mission and vision. As a product manager, you need to understand and lead that vision. It should impact everything you do, including what you write in your product updates.

The best way to manage expectations with customers is to guide them on the journey of your product.

Ask yourself questions like:

• Where is our product heading? What is the big picture?
• Why are we heading in that direction?
• How does our direction help our customers be more awesome?
• What won’t we be doing? Why not those things?

As you explain each update and change, you should keep those questions in mind. Make sure what you tell people aligns with that goal.

For example, with Lighthouse, our focus is on making managers great. We know they’re busy, so things like speed and performance in our product is as important as a new, shiny feature. We need to work reliably for them.

That meant that when we had a product outage due to Mandrill failing, we decide to switch email providers to Postmark. Here’s how we framed that:

Obviously, this is a very simple version of a story. For new, big features, there’s *a lot* more I would speak to explaining how we think it fits their workflow, why it matters, and how it fits into everything they do.

3) Explain your reasoning

While telling your story is important, it’s also helpful to have a rational side to it. What was the motivation for this decision?

If you’re doing product management right, you already wrote a product spec or product thesis that explains to your internal team why you’re choosing to work on this feature next. You should translate that same quantitative and qualitative data to a version that makes sense to share with your customers.

As Sinofsky points out, if you don’t give people a reason, they’ll make one up. So plan to give them a good one.

A feature can be commonly requested, but you don’t build it because it doesn’t fit your vision and mission. A feature can also be less commonly requested, but only because people can’t use your product until you build an integration they would need.

Either way, you would want to explain your decision. Tell people why you chose this of all the things you could do.

Maybe you have a Slack integration, and with all the hype and press around Microsoft Teams, you realize it makes sense to allow MS Teams users to do what you already allow in Slack.

Or maybe your company is moving up market and that means building some permissioning and security is now more important. Your SMB customers may not be as excited, but if you can help paint the picture that, “one day your business may grow and you’ll want to use these, too” can give them a better feeling about it.  Explaining the upmarket move can then also signal to your handful of current, big customers that you are investing more in what matters to them.

If you just say, “We built some new security features” with a list of bullets, you give your customers no idea why.  Do better than that.

4) Paint a picture of the future

Your product update is a snapshot in time. It’s one step in an endless journey towards (or keeping) product-market fit.

As important as it is to explain what you built and launched this time, you also should paint a picture for the future. Help people understand and anticipate what is coming.

The key here is to strike a balance. You do *not* want to publish your whole roadmap; it can change too much, and you want to give yourself some flexibility.

At the same time, if people know how you’re thinking and what you’re working towards, they can help you in a variety of ways:

• Volunteer to give feedback: If they know you’re building things they’d like, they’re more likely to reach out.
• Good customers stay: Most people hate switching products. If they feel like you’re heading in the right direction, they’ll give you time to fix problems and get there.
• Tell their friends/colleagues: When a product “just gets me”, you’re much more likely to rave to friends about it. By telling your story for features and where you’re heading, it builds excitement and anticipation for your best fit customers.

Strike the right balance on what you share

Giving just the right amount of detail on the future is definitely a learned skill. However, as a starting point, I like to do the following:

• Talk about things under construction: If you’re already committed to and building something it’s pretty safe to hint at it by showing a small snippet, or explaining what it will do.
• Focus on themes: Rather than listing the 27 things you hope to do (and could change), tell them thematically about your goal or vision. This could be like saying we’re going to “allow you to do key activities on your phone you told us are important when on the go” instead of listing mobile app features.

5) Seek feedback and input

You should never send something product related that is “no reply”, and this is especially the case for product updates. If people have something to say about what you built, make it as easy as possible for them to share their thoughts.

You can then use this to also recruit people for future customer development based on the upcoming features you’re going to launch, or to get people to take a survey.

The more you show you’re listening and acting in their interest, the more engaged your customer base becomes.

Creating a virtuous feedback cycle

When I joined KISSmetrics, they were getting about 10 pieces of customer feedback a week from our feedback box in the product. Unfortunately, no one on the team was replying to those for a variety of reasons.

Through being more customer driven, replying to those messages, and sending notes like I’m outlining today, we were able to boost that to getting over 50 pieces of feedback (5X) a week while the customer base doubled. This helped us catch and fix bugs faster, and more easily get insights from our customers.

The easier you make it to give feedback, and the more you respond and act on what you receive, the more feedback you’ll get from customers.

Before long, you’ll find it’s really easy to find and recruit customers for new feature feedback and customer development.

Adapt this to fit your business and audience.

With my startup, Lighthouse, we sell to managers. They’re generally in an office and live in email. This makes an email update great.

Once a month is a good cadence for us to send an update out as it’s a couple sprints, and usually enough to fill up a good update.  It also is a frequency that resonates with our audience as they do a lot of their projects in monthly increments.

Your business may be different, so consider changes to what I’ve outlined here like:

• Message on another platform: Can you tell them in Slack, via a small text, or somewhere else they’re most likely to check?
• Tweak the frequency: Update your customers as often as you think fits your update cadence and your customers want them. More, shorter updates, or fewer, longer ones may make sense.
• Use another format: If you’re a video platform, then video updates probably are better. If your business includes a really popular podcast, maybe a quick audio clip fits.
• Show your personality: This is a huge opportunity to build your brand, so put some of your company’s personality into it. If your company is nerdy, be nerdy, if it’s playful or irreverent, be irreverent, and if you’re really formal, then your update should be, too.
• Involve the right people: Who has the strongest relationship with your customers? They should be in the loop on this. For example, if you have account managers it may be best to have them get the word out, at which point you could draft something they can copy/paste and adapt.

The best way to get to the right format and approach for your customer is to listen and iterate. Get the right people involved in your company and start trying things.

As you build the habit of doing this, you’ll see more of what works and doesn’t so you can work towards getting messages like this from your customers:

How do you update your customers about changes and improvements to your product? Share your favorite tactic in the comments so everyone can learn.

And if you want help mastering key product skills like interviewing customers, writing product specs and updates, driving new growth, and reducing churn, I’m doing a limited number of coaching engagements for VPs of Product and First PMs at startups.

Learn more about how I can help you here, or sign up for a free call to talk about your needs here.

This was originally a 20-Tweet long Tweetstorm by Steven in 2019, but it’s no longer live. I reached out to Steven and he shared the text of those with me, which I’m preserving below. (Note: You can follow Steven on Twitter at @stevensi)

It’s great advice that should not be lost and complements a post on sending product updates I wrote around the same time that incorporated his advice into it. It’s a habit any good product manager should practice.

Steven Sinofsky’s Advice for Product Updates

For this post, anything in italics is Steven’s words, and regular text is my words. Any edits to Steven’s words across these 20 tweets is only for grammar, spelling, or formatting (bold, subheadings, and line breaks were my choices).

Here’s Steven’s advice:

Say your product has a new feature or change and you want to tell everyone about it with a blog post or some tweets. Here are a few things to think about when communicating change to a tech customer base

tl;dr Saying what you did and that customers asked for it isn’t enough.

With SaaS and agile we see many product releases that are primarily incremental feature releases. It might feel like a big release to product team, but to customers it might not be so big. To customers it might just be change. Doesn’t matter how much code it was for you.

For customers, something that is 10% better can often be 100% different. In order to be better, change no matter how big or how small, needs context and motivation for the change.

Who is the change for and why?

Dissatisfaction with change happens when there is a mismatch between expectations and reality. That gap can be closed if expectations have a chance to get set or leveled with context and communication.

The most important thing is never to communicate some change or new aspects to a product in isolation.

Is this it? Is there more? Why?

Product strategy matters.

Customers will invent your strategy if you don’t tell them.

If they are wrong the satisfaction gap widens.

“Why”?

Most common tactic (I say mistake) is to make a change to a product and put out there “people have been asking for this” or “feedback.” If you have more than like 100 users that is just axiomatic. It is also a bit presumptuous—did everyone reading this ask?

It is trivial to make a big deal out of fixing bugs, but that has a thirst to it—like you’re asking for credit for doing the basics of offering a product. People generally don’t ask for bugs to get fixed, they just think less of the product.

“Most requested” is very dangerous. What else was requested? Was there a vote? Why did you do this request and not all the other requests? Where are requests tracked?

In general, requests is not a sustainable approach to prioritization. (Ed note: Steven and I agree on this, which is why I explain in detail, “Why Feature Voting Creates Poor Products “)

What is more interesting than saying something is requested is articulating the reason for doing something that was not requested. That’s why products exist—to solve unarticulated needs not build faster horses. Teams exist to have a vision, not just fix their own mistakes.

When communicating change, it is easy to go into all the details of the change.

What is far more interesting is to explain the problem and then go through the process of how you arrived at this specific solution versus others. Was the change really necessary?

The internet will just do so for you even if you don’t.

You might try explaining that a problem is “ease of use” but unless you have specific flows and scenarios, then others will just come up with different designs and problems.

This is especially true for UI changes.

If you make a UI change you should expect people to ask for the option to turn it off. So in communicating it you should explain why it is the new “one and only” way and what is the strategy behind it.

Offering options is actually really hard in practice, the more options are offered the more people will expect them. So if you do have an option for one change and make a big deal out of it, then expect to be asked for options every time. That’s serious combinatorics.

Most changes have some data behind them—not all but most.

Your case will be much stronger if you present the data you used to make a choice: How many people use X? Is this optimized for mobile or web? What platforms? How slow then, fast now?

If you don’t present data but imply there is data then you will be debating the internet to make your case. The internet is made up of anecdotes and it will get very messy.

A corollary is not to use anecdotes yourself. “Many people requested this change” is in fact an anecdote so is “people prefer” and “feedback we received.”

If you don’t have data then supporting changes with a strategy, point of view, or related business case can be useful. Making changes that might be unpopular is part of the job but if you don’t offer anything the internet will make up a reason and you won’t like it.

The most difficult part of communicating change is the people listening and engaging are almost never fully representative of your entire user base or even target for change.

Using data to show that can help. Intellectually this is understood, but emotionally not usually.

Personal view. Write the long blog post. Maybe you choose not to publish it, but if you write it then you will know all you will face.

You might show the post to detractors, reporters, or some outsider to make sure all views are covered.

Sometimes when you make a change you don’t have to make a big deal about it. More often than we like people just don’t notice. That’s ok. // END

Writing a quality product update is an important part of communicating as a product manager.

Much like writing a great product spec helps you communicate internally, your product update helps you communicate externally with customers, the press, stakeholders, and your market.

If you’re looking for more insights on writing a good product update, you can read my post that builds on this here: How to Write Product Updates that delight Customers and Reduce Churn

…and you can subscribe to Steven’s substack on product development here https://hardcoresoftware.learningbyshipping.com/